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ABSTRACT 

A battle group commander’ s successful employment of the assets in his 
battle group heavily relies on his conceptualization of the pragmatic 
capabilities of each of these assets. This thesis comprises an inter- 
active decision support system (DSS), which utilizes database manage- 
ment and high resolution computer graphics, to assist the commander in 
meeting this challenge. The DSS incorporates data on specific systems 
installed on each unit as the basis for user developed capability effec- 
tiveness/system coverage displays. The system is designed to be opera- 
ted through discrete speech voice recognition equipment. 
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I. E AC K GROUND AND OVERVIEW 



A. ANOTEER DECISION AID !? — A DEFENSE 

... I never needed any computer to make a decision for 

me our success just gees to show ycu don't need 

any of these fancy computer systems when it comes right 
down tc trass tacks...* 

Six months into development, of a thesis which was 
designing a computer based Decision Support System, this 
statement is somewhat provocative. Recently, this author 

sat in an audience captivated by the dynamic commander who 
was on stage. A portion of his closing remarks included 

the paraphrase which headed this chapter. Was the connota- 
tion of his statement mors than his egc-invclvement spawned 
by the euphoric taste of success? 

The mandate of command is to make decisions when opera- 
tions "come down tc brass tacks." There is no such 
mandate for a computer system. The commander who doesn't 

avail himself of all sources and methods of display of 
information cannot be as confident of his decisions as the 
commander who does. The complexity of ccmtemporary peace- 
time and wartime operations, in concert with technological 
advancements which are cccuring at near exponential rates, 
is often times characterized by too much information to 
digest, hewever. Computer supported decision making can 
overwhsli and often dilute human capabilities by prolifer- 
ating the volumes of knowledges which a user feels compelled 
to assimilate. This gives rise to a common malady in the 
Military, "decision aid angst." 

Originally, computer systems focussed on abilities to 
manage massive amounts of information, a Management 
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focus has 



Information System (KIS). flora recently, the 
shifted to translating existing technological capabilities 
into Decision Support Systems (DSS) . The DSS channels the 
massive data processing capabilities of today's computer 
technology towards the "decision" and away from demon- 
strating how much data can be manipulated. DSS, in the 

purists' view, is an extension of the inner vor kings of the 
commander himself. The commander has participated in its 
design, and it then allows him to make a comprehensive deci- 
sion based on information organized for presentation in a 
format he desires. Row the designer of the DSS defines the 
user-system interaction requirements as well as the format 
of the information display, becomes the difference between 
whether the power to the system is "on" throughout the deci- 
sion making process, or "off," archie ved for "future use." 

This thesis addresses an interactive decision support 
system for a battle group commander, to enhance the effec- 
tive management of the assets assigned to the bartle group. 
It focusses on a realistic dialogue [Ref. 1] and substantive 
information representation to expand its useability and not 
dust collecting capability. 

B. DECISION SUPPORT SYSTEMS 

Fcr a Decision Support System to have long-term utility, 
it must be the result of an "evolutionary " design process. 
This process must address both the evolution of the tech- 
nology, and that of the user. 

The necessary iterative design process relies on short- 
term feedback between the user and the developer tc ensure 
that required change is implemented in the short term. 
This process applies to the three fundamental subsystems of 
a DSS, dialogue, data management, and model management. 
[Ref. 1] 



15 



This thesis addresses a specific component of a battle 
group commander ' s sphere of responsibility, asset manage- 
ment. It has been developed based on this author's experi- 
ence in Fleet operations. 1 As the designer and user of the 
ESS, the precepts discussed above, fundamental to the design 
of a ESS, have been met. Extension of the applicability to 
follow-cn user groups would necessitate '’evolutionary" fine 
tuning tc each group. This DSS is based on a schema of 
management of a capabilities database of a designed battle 
group, and translating that database into descriptive 

computer graphics displays. Control of DSS operations 
with respect to user-system interaction represents state of 
the art technology in the utilization of voice recognition 
protocols. With the use of voice, the user is thus free 

from the confines of a terminal keyboard. The system, as 
developed, does not represent a stand alone DSS in the 
complete sense discussed above. The "Model Subsystem" 

[Ref. 1 ] is manifested in the tactical knowledges of the 
user, and not an analytic or mathematical model. 

Incorporation of such a model or models is an obvious 
follow-cr. enhancement to the system. Less a model 

subsystem, a semantic title of "Decision Support Subsystem" 
may be contemplated, however, in actuality, this system does 
operate based on a model, the user. The "model" which this 
ESS utilizes, resides in the mind, experience, and fibre of 
a user, which has teen hcned throughout a career. The 
cutgrcwth of this system is an extension of the commander's 
"mind's eye," an interface between the conceptual and the 
real. In formulating the best employment of his battle 
group, based on the capability (sensor and weapons) of each 



1 The author has particioated in 6 READIEX, 3 FLEETEX, 
and numerous other warfare exercises. This experience has 
included functioning as a principle watchstander for the 
ASWC, ASUWC, or AAWC in the majority of these operations, 
addit icnallv, the author has attended the TACTRAGROPAC Staff 
Tactical Training Course. 
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this DSS allows the commander to 



ship in the force, 
nally visualize the interplay 
assets. 



of capabilities 



<= Yt ~-r- 



among these 



C. DIALOGUE SUBSYSTEE DEVELOPMENT 

Any system which encompasses a man-machine interaction 
must strive for that illusive "symbiotic" relationship where 
man and machine are in harmonic unison with each ether. 
The principle stumbling block to achievement of this goal 
has been the format of the language which joins the two, 
English versus "Computerese." Additionally, the "angst" 
mentioned earlier can be an outgrowth of a deficiency of 
clerical skills on the part of the user, at the interface. 
The challenge is accentuated by the speed mismatches between 
man and machine "thinking. " The issue is to construct a 
common language at tie interface, where the goals and inten- 
tions of the user are easily translated into the logical 
courses of action of the computer. [Ref. 2] 

Can a computer really be friendly? This question 
should mere accurately replace "computer" with "computer 
software designer." Therein lies the source of many of 

today's misgivings. The software designer mus t be attuned 

to the real world requirements and not just code formats or 
primitives. If the designer looks at the man-machine envi- 
ronment, and accurately interprets it, then computers can 
indeed be "friendly." Users, by their human nature, have 
expectations. Therefore, a computer system shculd be 

predictable. The adversarial relationship which could 

develop between man and machine is eliminated when the user 
is given responses from the system which reinforce a confi- 
dence that the information is "shared," and not one sided. 
This relationship is further cultivated by the system 
returning positive feedback to the user when a response is 
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entered, a stop-gap fcr potential anxiety. When all these 
concepts are merged, the key which unlocks the puzzle points 
to "vocabulary." ( Ref. 3] 

This DSS has taken into account the vernacular of the 
tattle group and interfaced it with the vocabulary of the 
computer. Going one step further, the input medium, with 
voice recognition, has allowed the evolution of the inputs 
into a conversational and not c ommand format. Flexibility 
has been incorporated into the formats by allowing multiple 
options fcr each component of a conversational construct. 
Therefore, consistency is met while concurrently allowing 
flexibility to meet the user's multiple needs. Internal to 
the system, this practice moves one step further with 
ccmmcnly used conversational inputs grouped into single word 
inputs, when feasible. 

Finally, the value of operating the system through voice 
control cannot be overstated. Not only does this interac- 
tive format free the user from translation of his thought 
processes through a keyboard, but also provides mobility 
throughout the work center or watch station, while main- 
taining control of the system. The pragmatics of the 

conversational interactions in this DSS, while accomodating 
multiple options, nearly exhausts the 256 utterance vocabu- 
lary of this discrete speech equipment (Threshold 
Technclogy's T-600). However, while the obvious extension 
is to convert the DSS to a connected speech technology, when 
properly trained, the T-600 has shown remarkable ability to 
discriminate utterances and handle the demand. 

C. EISICN PHILOSOPHY 

There were three principle design philosophies which the 
author adhered to in developing this DSS. First, the 
system is s urv i vab le , or in another parlance, "rob us t. " 
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The query/response sequences are all supported by system 
error checks to preclude unintentional "bombing" of the 
system, and reduce user apprehension. Each view which 
requires a user response shows examples of correct 

responses. The differences between the entry formats for 

keyboard and voice are illustrated, in detail, in the User's 
Manual, the third chapter of this thesis. In addition to 
providing as error check cf the inputs, the language is 
simple and replicates how the user would normally articulate 
the parameter being addressed. Additionally, the User's 

Manual shows example sequences through a complete session 
with the system, reproducing the logical inputs and system 
responses, as well as errcr recovery features. Finally, 
the DSS is con s ist ent. in that the types of entries and 
their respective results are identical throughout the eight 
modules cf the system. 

E. GRAPHICS — IMPROVING PERCEPTION OF CAPABILITIES 

The "acid test" of the performance cf any sensor or 
weapons system is in actual operations. When these opera- 
tions are with an adversary, whether in an exercise or real 
world, the preparatory thought given to rhe employment of 
those assets significantly impacts on their aggregate 
performance. In assimilating the huge amounts of data 

required to make a credible decision as to asset employment, 
timeliness requires the commander digest that information in 
"chunks." The results of numerous studies have borne cut 
that visual perception of large amounts cf information 
significantly increases human ability to draw inferences and 
make subsequent judgements. The same graphics display may 
represent differing interpretations to different people. 
However, the "evolutionary" design process of a DSS, 
precludes this eventuality by having had the commander 



19 



provide the input as to the design of the displays, and 
thereby the format of the information represented. [Ref. 4] 

The graphics capabilities of this DSS reflect state of 
the art graphics technology. The applications programs for 
the displays are written utilizing the DI-3000 software 
language. The only shortfall of the hardware in use is 
that it dees not allcw complete filling of overlapping poly- 
gons (principally circles in this case) on the same view. 
This reduces the effectiveness of the overall sensor/weapons 
coverage displays by having multiple circles shown vice one 
solid area for force coverage. The bottom line, though, is 
that the graphics displays, regardless of this shortfall, 
enhance by several orders of magnitude the value to the 
force of radar "a" or weapon "b," in comparing their net 
effectiveness. This comparison is presented in relation to 
the ether comparable systems in the force to provide a 
comprehensive, "net” effectiveness display. 

F. ASSET MANAGEMENT DECISION SUPPORT SYSTEM 

This thesis is organized into three chapters; an intro- 
duction, a discussion of the software development, and 
finally, a comprehensive User's Manual for operation of the 
system. It is essential to point out at this juncture, the 
design has attempted to maximize the ease with which a user 
interacts with the system, and therefore, the User's Manual 
can assume a more appropriate application as a reference 
rather than a mandatory prerequisite for operation. 

The battle group assets addressed in this DSS are these 
commonly found in a carrier or surface battle group, with 
their supporting Service Force ships. In the interest of 

economy , for a carrier battle group, only fighter and AEW 
airwing assets are considered. The general functioning of 
the ESS is initiated with the input of the names of the 
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ships which will compose the battle group. The ship names, 
in turn, are the key elements of database records, which are 
reflective cf that ship's senscr, weapons, and UHF/HF ccmmu^ 
nicaticns capabilities. To afford maximum dissemination of 
not cnly this thesis, but also the DSS concept, the ship 
databases have teen developed from unclassified sources. 
However, the design of the files containing the data, 

readily facilitates the transition to a classified database. 

The focus of this DSS is to afford the battle group 
commander a vehicle whereby he can "build" a battle group 
from specific units with th eir specific capabilities and not 
typical class capabilities. Whether it be a theoretical 
formaticr cf a group of representative ship types, or a 
composition of task organized units, the system will orga- 
nize and display the performance capabilities of the 
sensors and weapons which are organic to the developed 
group. The operations of the DSS revolve around estab- 
lishing the positions of the ships from designated "ZZ" 
position, then allowing the user to display to the terminal 
screen specified weapons and sensor capabilities, as well as 
displaying to the graphics monitor the translation cf equip- 
ment capability into coverage or effectiveness areas for 
each asset. A distinction is made here, between terminal 
screen and graphics monitor, as the system can accomodate 
two categories cf installations; those with a graphics 
interface, and those without. While the design encompasses 
a full graphics display capability, with the terminal 
displays providing supplemental views, the supplemental 
views are comprehensive and can stand alone should the user 
have nc graphics capability. For operation of the DSS 

without a graphics capability, the user should refer to the 
introductory sections of the User's Manual. 

With the graphics capability, once the coverage areas 
have been displayed, the user can expand the detail of the 
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view ty displaying a cartesian coordinate grid ard/cr an 
appropriate threat sector. Additionally, with an eye 

towards projecting the tactical impact of moving a unit, the 
user is afforded the opportunity to manipulate the positions 
cf the force units and observe the subsequent change in 
force sensor or weapons coverage effectiveness. 

Mere towards the administrative aspects of battle group 
operations, the Composite Warfare Commander (CWC) organiza- 
tion can be constructed, managed, and changed. 

Additionally, a real time view of the composition of the 
varicus circuits in the battle group communications plan is 
available. In the COMMS module of the DSS, the communica- 
tions nets can be displayed with the participating units, as 
dictated by mission area, shown. An extension of the 
communications views is a comparison, on the UHF nets, of 
the units who are out of UHF cemm range with the Net Control 
Station. A final administrative capability of the system 
is allowing the user to enter explanatory remarks for a 
unit, to be included in that units database for future 
access/disp lay . 

G. FC11CW-CN ENHANCEMENTS 

The primary goal of this thesis has been to initially 
develop an interactive Decision Support System, controlled 
through voice technology, which facilitates a battle group 
commander's management of his assets. There are several 
enhancements to this CSS which could be addressed by future 
efforts. 

• Conversion to Connected Speech Voice Technology 

• Incorporation of SHARPS and IREPS data as alternatives 
to tte system default sensor capabilities 
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• Expansion of the database and display capabilities to 
allow display of the opposition sensors and weapons on 
the same view 

• Conversion of the software to micro-computer/desk top 
use 



• Adaptation of the DI-30 00 "Pick*' function allowing iden- 
tification of monitor coordinates from a "Byte Board" 
device 

• Incorporation of performance models which would drive 
the positioning cf the force units 



• Interface with a wargama to allow representation of 
capability displays unique to the composition of the 
battle group in use 



• Incorporation of 
capabilities with 



mapping 
respe ct 



libraries to allow display of 
to a specific geographic area 
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II. D ECIS ION S D EPORT SYSTEM SOFTW ARE DEVELOPMENT 
A. INTRODUCTION 

The previous chapter discussed the rationale for the 
development of this thesis, as well as structure, and some 
cf the key components of the design utilized. This chapter 
addresses the development of the software which supports the 
Decision Support System. The discussion will cover the 
schema utilized for the system, definitions of common system 
variables, as well as a general overview of the construct of 
the system modules. It is intended that this chapter be 
utilized in concert with the system program (not attached to 
this paper) , which is written with algorithmic descriptions 
incorporated into each program unit. 

E. PROBLEM FORMULATION 

The fundamental challenge of this thesis was to develop 
a functional support system for a battle group commander. 
This system was to prcvide for the display of specific force 
databases, as well as be capable of translation of certain 
capabilities in those databases into discernible computer 
graphics displays. Parallel to these efforts, development 
cf a functional user - computer dialogue format was consid- 
ered essential. In short, therefore, this thesis addressed 
the challenge of developing an interactive computer database 
management/ccmpu ter graphics system, which was "user 
friendly," and incorporated the capabilities of today’s 
battle groups. 
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SOLUTION STRUCTURE 



The program was written in FORTRAN-77, American National 
Standard (ANSI X3.9-1978), with extensions developed by 
Digital Eguipment Corporation (DEC) [Ref. 5] for execution 
cn a VAX 11 or PDP-11 series computer. Additionally, the 
DI-3000 graphics language is utilized for the graphics 
unique capabilities cf the system. The control medium for 
this system accomodates commands from the terminal keyboard, 
as well as commands entered through discrete speech voice 
recognition equipments. The Threshold Technology's T-600 
was the vcice input device for this program. However, any 
compatible equipment could be utilized. The graphics 

cutput was generated on RAMTEK high-resolution graphics 
interfaces and monitors. 



E. EECGFAN GENERAL SCHEHA 

Fcr the ease of software design and program testing, 
this system was designed around the construction cf eight 
(8) major modules. With the exception of the AIN 

Nodule,” each module comprises an assemblage of subroutines 
which focuses on the features incorporated in than module. 
In cases where a subroutine is required by more than three 
(3) sections of the program, that subroutine was included in 
a general section, at the end of the program. As an exten- 
sion of the program itself, succeeding topics in this 
section will address the design of each module group. In 
addition, a glossary, by block common designations, will be 
provided to facilitate following rhe flow of the program. 



E. SIGNIFICANT ADJUSTHEHTS 

There ware five principle areas which were cumbersome in 
the development cf this program. They are enumerated below 
with mention of the vehicles by which they were overcome. 
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a. Management of the Databases 

There were four databases developed for this 
system. The first, the Master Database, contained coded 
capabilities for 130 Pacific Fleet units, with seme addi- 
tions to provide AEGIS assets. This database was oriented 
around the name cf a particular ship. The database would 
be utilized by the user, in identifying the name of a battle 
group unit, and the system locating the record associated 
with that ship and reading the record. For ease of manage- 
ment, an index ed- keyed access format was utilized for this 
file. The primary key field was the name of the ship. 
The secondary key fields were the first two and first three, 
respectively, characters of the unit's hull designation. 
The secondary keys were so devised to enable distinction 
between guided missile equipped units and those which were 
not. The DEC extensions which address these capabilities 
are discussed below. 

The second database was incorporated into the 
system to allow the user to use the short form name of a 
ship, fox example, "FOSTER" for "PAUL F FOSTER," or "CONNIE" 
for "CONSTELLATION." This distinction was important, as the 
master database utilized the full name of the included 
ships. This database file was also formatted in a keyed 
indexed manner. 

The third database was actually a group of -three 
files which contained the database elements for the partic- 
ular tattle group, which were developed by the user. These 
files used a sequential access method. 

Finally, the communications circuits in the 
battle group COMM plan were stored in a seperate database or 
file. The composition of this file was, again, a keyed 
indexed organization, based on a primary key of circuit ID 
numbers. The file contained the ID, circuit name, 

frequency range, and net control station. 
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(1 ) Index ed/Ke yed Orq anizacion Acc ess . 

Records in an indexed file are ordered by the fields of 
those record elements designated as key fields. This orga- 
nization, then, specifies the order of processing of the 
records in the file. You must specify the locations within 
the records of the primary key field (mandatory) , and any 
alternate key fields. Once the record corresponding tc the 
identified key has teen located, this organization type 
allows sequential access to succeeding records in that file 
if desired. [Ref. 5: pp. 7-3 to 7-5] 

t. Correction of a Capability in the Master 

Database 

There were foreseeable situations where a change 
in a unit's capability was to be incorporated into the 
Master Database. This eventuality is accomodated, by 

allowing manual input of the change in capability. In 

crder to adjust the Master Database to reflect this change, 
a REWRITE feature was utilized. 

(1) REWRITE a Record in a I nd exed/K eyed File. 
The REWRITE feature transfers output data from internal 
storage into the current record in an indexed file. You 

must first locate the record you desire to change, with a 
READ statement, then REWRITE will update the record as you 
have indicated. In this program, only FORMAT TED RE WR IT S 
statements were utilized, indicating that the record had a 
specific format associated with the data entries. [Ref. 5: 
F- 7-37] 

c. Conversion of Ship Name into Graphics Integer 

Form 

Unique to the DI-3000 graphics language, the 
text primitives displayed on the monitor are required to be 
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in internal/integer form. The difficulty arose when the 
ship's names, which were CHARACTER* 1 9 variables, were 
required to be displayed along with the force capabilities. 
The necessary conversion of these character variables to 
internal form was accomplished through the use of the DECODE 
extension. 

(1) DECODE Operatio ns. The DECODE statement 
allows the conversion of character variables into internal 
(binary) form according to a specified format statement. 
For display to the graphics monitor, the names of the ships 
were transformed from their character form, and segmented 
into a five element integer array which was the useable form 
for display. (Ref. 5: pp. A-1 to A-2 ] 

d. Segmenting a Multi-Element Command String 

In several of the display modules, the number of 
available options reguired the system to be able to discrim- 
inate the key portions of multi-element commands. An 

example of this requirement is reflected in the command 
string "DISELAY UNIT SI MITZ . " Each component of this three 
element command was selected from several options. These 
options additionally were of differing lengths. The 

system, therefore, had to break the command into these 
components. The command was read into the system as a 
thirty-four (34) element integer array, and through the use 
of the ENCODE extension, the program converted each of the 
appropriate command elements into their proper character 
formats . 

(1) ENCO DE Oper ation s. The functioning of the 
ENCODE extension is identical to that of the DECODE func- 
tion, only in reverse. The integer command string was 
first broken into segments, with the position of the spaces 
indicating a new element. Next, each of these integer 
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segments was transformed into character form according to 
the format required for the particular command element. 

(Eef. 5: pp. A- 1 to 2-2] 

1 • Or i entation cf S hip Names on G raph i cs Plot 

Depending on the scale in use when the graphics 
capabilities of the system were utilized, a great deal of 
clutter reduced the effectiveness of the display. This was 
predominately due to the congestion involving ship names in 
close proximity. This clutter was reduced by orienting the 
name cf the ship commensurate with its relative position in 
the display. The subroutine "ORIENT," to be discussed 
later, made a comparison of the position of the unit to be 
displayed, with respect to the plot quadrant it was in. 
Eased on the result cf this comparison, the DI-3000 "JJUST" 
call was controlled to reduce the numbers of overlapping 

names. The function of the "JJUST" subroutine in the 

EI-3000 language is to orient the display cf text at the 

position specified. The call to this routine will cause 
the text to be "justified" at its center, left, or right 
sides, as well as with respect to the top or bottom of the 
letters in the text. 

F. DSS FILE COMEOSITIOH 

This Decision Support System resides in the Wargaming 
Analysis and Wargaming Laboratory (WAR LA 3) at the Naval 

Postgraduate School. The user name under which it is oper- 
ated is called "DECISION." Should this user account net be 
available on-line, tbe complete system is available on tape 
in the Lab. The main program, object, and execution files 
all have the "DSS" name associated with them. The 

following files support the operations of the system and are 
organic to this account. 
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• FCR01 1 . CAT This file contains the master database 

for the DSS. The database is a formatted, keyed access 
file as discussed above. It is from this file that the 
program will automatically locate the database for the 
ship identified, and transfer that data into the battle 
group operating databases. 

• FCRO 12 . CAT This file is a keyed access formatted 

file which contains the shcrt form names of some of the 
ships in the master database. When the system searches 
the Master Database to extract the capabilities of a 
unit, should a name match not occur in this search, the 
system will first check this file for a short form name 
match and conversion to the full form name, before the 
unit will be "flagged" for manual database entry. 

• FCR0C7. CAT This file is created through the func- 

tioning of the system. A "SAVE" capability, allows the 
user to store the data which he/she has developed, and 
terminate the session, resuming it at a later time. 
This file is sequentially organized and contains control 
variables, number of ships in the battle group and their 
names. It is used, when the user next initiates a 
session with the system, to reaffirm that a battle group 
had teen formed previously. 

• FCRQC8 . DAT This fils is also generated when the 

"SAVE" feature is exercised. In addition to the names 
of the units, as was available in FOR007.DAT, this file 
alsc contains the complete database for the units 
designed into the particular bartla group. This is 

what is referred to in rha system as the "battle group 
database." It is read into the system, and is orga- 
nized through the use of linked lists. A representa- 
tive record in this file is more comprehensive than its 
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counterpart in tie master database. This database will 
reflect current capabilities, as well as user generated 
information as tc unit position, explanatory remarks, 
etc. This file is sequentially organized. 

• f CRQQ9. CAT This is the third file generated by 

exercising the "SAVE" feature of the system. The 
Ccmpcsite Warfare Commander organization is stored here. 
The contents of this file are the names of the warfare 
command ers/coordinators , the respective organizations 
functioning in these capacities, and the unit on which 
the respective ccmmande r/coor dir.ator is embarked. The 
file is sequentially organized. 

• FCR0 19. DAT The communications plan structure is 

ccrtained in this resident file. As with the master 
database (FOROI 1 .EAT) , this file is referenced from the 
CCKMS Module, however, the information contained therein 
is net transferred to D S3 for manipulation. This file 
has a keyed indexed organization based on the primary 
key of circuit IE number. The remainder of each record 
certains the name of the net, the net control station, 
the frequency range, and the applicable mission area for 
which this net is used. 



6. EICCK COMMON VARIABLE DEFINITIONS 

In an effort to minimize the necessity for passing large 
numbers of variables between using subroutines, extensive 
use was made of "Block Common" constructions. These blocks 
grouped those variables whose use was similar, and whose 
data type was the same. As a reference to be utilized when 
reading the program, the following sections address each of 
these blccks and define the variables which are contained 
therein. It is not the intent, however, that a complete 
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discussion of the range of possible variable values be 
included. For a ccnprehe nsive review of the values which 
the variables could assume, reference should be made to the 
User's Manual, chapter three of this thesis. The array 

dimension of the particular variable is shown in paren- 
theses. 

a. BDAT1 NUMSHP , FIRST, FREE, LINK(25) 

This block groups the basic integer data 
regarding the organization of the battle group database. 
Ihe definitions of the variables contained in this block are 
as fellows. 

• SUM SHF Number of ships in the battle group 



• FIRST Header for the battle group database linked 

list 



• FREE The first available record position in the 

battle group database 

• LINK Battle group database link values 

b. BDAT2 HULL (25) , UNIT (25) , REMARKS (25) 

This block contains the complement to the 

integer base data for the battle group database, the base 
character variables. The definitions of these variables 

are as fellows. 

• HULL — A *6 variable representing the hull number of 
tfce ship 

• UNIT — A *19 variable representing the name of the 
ship 

• REMARKS — A *25 variable of a general nature, input 
by the user as descriptive remarks about the respective 
ship 
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c 



P0SIT1 COSYS, ZZ QUAD(25) 






This block organizes one of the two positioning 
variable groups, and represents the character variables 
involved with the ship positions. There is an additional 

position block which is unique to graphics displays and is 
addressed seperately. The following is the composition of 
this block. 

• COSYS — A *5 variable indicating the type of coordi- 
nate system in use (polar or cartesian) 

• ZZ -- A *19 variable indicating tThe name of the unit 
at "2Z" 

• CUAE — A *1 variable indicating the position quadrant 
of a unit (implies cartesian positions are being used) 

d. P0SIT2 XPOS(25) , YPOS(25), BENG (25) , 

ENG (25) , SPEED (25) 

This block complements the previous variable 
grouping with the integer variables associated with the 
positioning of the ships. The composition of the block is 
as fellows. 

• XPOS — The position of the ship in the "x" direction 
(implies the use of cartesian coordinate system) 

• YPOS — The position of a ship in the "y" direction 
(implies the use of cartesian coordinate system) 

• ESNG — The bearing of a ship from "ZZ" (implies the 
use of the polar coordinate system) 

• ENG -- The ranee of a ship from "ZZ" (implies the use 
cf the polar coordinate system) 

• SPEED — The maximum speed of a ship 
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€. ADM INI CRUDES (25) , DESRON(25) 

This block includes the character variables 
which represent the elements of the administrative organiza- 
tion cf a unites database. The composition of this tlcck 

is as fellows. 

• CRUDES -- The cruiser destroyer or carrier group to 
which a ship is assigned 

• DESFON -- The destroyer squadron to which a ship is 
assigned (not applicable tc aircraft carriers or service 
force ships) 

f. ADMIN2 PRMAR(25) / SCMAR(25) 

This block contains the primary and secondary 
mission areas of a ship. These are charactar variables. 
The composition cf the block is as follows. 

• ERMAR — A *3 variable representing the primary 

mission of a ship 

• SCMAR — A *3 variable representing th a secondary 
mission of a ship 

g. SCHRDR SRSCH(25), ARSCHA{25), ARSCHE (25) 

This block represents the search radars in the 
database. These are integer variables, and the composition 
cf the block is as fellows. 

• SRSCH — The variable representing the surface search 
radar onboard a ship 

• ARSCHA — The variable representing the primary air 
search radar onboard a ship 

• ARSCHE -- The variable representing the secondary air 
search radar (as applicable) onboard a ship 
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h. WEAPN1 PHAL (25) , G UN (25) MYSLA (25) , 

MYSLB ( 25) 

The parameters cf the weapons capabilities of 
the database are represented in this block. These are 
integer variables, and the composition of the block is as 
follows. 

• PHAI — The number of PHALANX systems onboard a ship 

• GUN — The variable representing the type of gun 

system cnboard a ship 

• MYSLA — The variable representing the type of primary 
missile system (as applicable) onboard a ship 

• MYSLB — The variable representing the type of secon- 
dary missile system (as applicable) onboard a ship 

i. WEAPN2 H ABF (2 5), TOMA(25), SLQ (25) 

This block contains the character variable 
complement of the weapons block above. The ccmpositicn cf 
this block is as follows. 

• HARE — A *1 variable (Y/N) indicating whether a ship 
has a HARPOON capability 

• TOMA — A *1 variable (Y/N) indicating whether s ship 
has a TOMAHAWK capability 

• SLQ -- A *1 variable (Y/N) indicating whether a ship 
has an AN/SLQ-32 capability. 

j. WPNRDR ? CRA (2 5), FCRB (25) 

The fire control radar capability of a ship is 
represented in this block. These are integer variables, 
and the composition cf the block is as follows. 

• ECRA — The variable representing the primary fire 
control radar (as applicable) onboard a ship 
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• FCRE - 


The variable representing the secondary fire 


control 


radar (as applicable) onboard a ship 


k. 


COMM SAT (25) , UHF(25), HF (25) , 

UHFAVL(25), HFAVL(25) 


ties cf the 


This block contains the communications capabili- 
ships in the battle group. These are integer 


variables. 


and with the exception of the SAT variable. 



represent the actual number of equipments. The composition 
of this block is as fellows. 

• SAT -- The variable indicating the type of satellite 
communications capability (as applicable) onboard a ship 



• DBF — 


The number of UHF radios installed onboard a 



ship 



• HF — 


The number of HF radios installed onboard a ship 


• CHFAVL 


-- The number of UHF radios available onboard a 



ship 



• HF -- 


The number of HF radios available onboard a ship 


1 . 


SENASW — - IVDS (2 5) , TASS(25), SONAR(25) 


sen ting the 


This block contains integer variables repre- 
types of ASW sensers available in the battle 



group. The composition of the block is as fellows. 

• IVDS — The type of IVDS equipment (as applicable) 

onboard a ship 

• TASS — The type of TASS equipment (as applicable) 

onboard a ship 

• SONAR — The type of sonar (as applicable) onboard a 
ship 
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o. WPNASW1 ASWBOC (25) 

This block represents the character variable 
indicating the type cf ASW rocket onboard a ship, as appli- 
cable. The representation of this variable is "A" for 
ASBOC, "S" for SOBROC, or " N" for NOT CAPABLE. 

n. WPNASW2 TORE ( 25) 

This block contains the integer variable repre- 
sentaticn cf the type cf torpedo onboard a ship. The 

composition of the variable is "I" for MK-46, "2" for MK-48, 
cr "0" fcr NOT CAPABLE. 

C. AIRCAP H ELC (25) , EM3(25) 

This block addresses the aircraft capability of 
the battle group with respect tc type of helicopters avail- 
able within the force. The composition of this block is as 
follcws. 

• HELO -- A *1 variable indicating the type of helicopter 
capability a ship has onbcard 

• EKB — A *1 variable (Y/N) indicating the erabarcat ion 
status of a ship which is helicopter capable 

p. COM AND C MD ( 8) , 0RG<8), EMBARK (8) 

This block contains the composition of the CWC 
Crgar.izatic r.. The representations of these character vari- 

ables axe as follows. 

• CMD — A *5 variable representing the name of a warfare 
ccmmander/cocrdinator — this value is fixed in the 
ELOCK DATA section of the program 

• ORG -- A *25 variable representing the name of the 
organization functioning as a warfare commander/ 
coordinator 
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• EMEAEK — A *19 variable indicating the name cf the 
ship on which the warfare commander/ coordinator is 
e irbarked 

g. RAMI OR D (37) , ABS(37), SCALE, SIZE, 

CHAR_SHIf 

This block contains real variables which are 
utilized in the graphics portions of the program. They 
relate to the graphics plot parameters associated with the 
display capability of this DSS. With the exception of the 
ORD and ABS variables, these values are fixed in the ELOCK 
DATA section of the program. The composition of this 

common block is as fellows. 

• ORE — Plot "x" position cf a ship or display feature 
(1-25 -- ships, 26-35 — ship temporary positions, 36-37 
— AEW/CAP features) 

• ORD — Plot "y" position of a ship of display feature 
(1-25 -- ships, 26-35 -- ship temporary positions, 36-37 
— AEW/CAP features) 

• SCALE — The scale (1-5) controlling the dimensions of 
the display coverage 

• SIZE -- A scaling factor applied to displayed graphics 
text primitives used to maintain balance with the plot 
dimensions 

• CHAR_SHIP -- A control variable used as the basis for 
the size of the ship name next primitives displayed on 
the screen 

r. BASPOS1 EASCUAD 

This block contains the charactsr variable 
representing the quadrant in which the ship functioning as 
"ZZ is positioned. The variable is utilized in the compu- 



38 



I 

tation cf the graphics equivalent positions of the remainder 
cf the ships in the tattle group. 

S. BAS POS 2 BASORD, BASABS, POSX, POSY 

This block contains the integer (BASORD ,BASAES) 
and real (PCSX, EOSY) variables which are utilized tc orient 
the graphics plot to the position of the "ZZ M ship. It is 
also used in computing the required offset for the display 
of the cartesian coordinate grid, an option in the graphics 
portions of the DSS. The composition of the block is as 
follows. 

• BASOED — The "x" position of the ship at "ZZ" 

• EASAES — The "y" position cf the ship at "ZZ" 

• PCSX -- The graphics plot "x" coordinate for the origin 
cf the cartesian grid display 

• PCS Y -- The graphics plot "y" coordinate of the origin 
of the cartesian grid display 

t. VIRTUAL LEFT, RIGHT, UP, DOWN, LPORT , 

RPORT, UPCRT , D FORT 

This block contains the parameters associated 
with the definition of the graphics display plot. They are 
tied tc the DI-3000 inputs addressing the WINDO size and the 
VIE WPCRT size. These are real variables and their values 
are fixed in zhe BLCCK DATA section of the program. The 
composition of the block is as follows. 

• LEFT The left dimensional limit for the WINDO of 

the graphics display 

• RIGHT — The righz dimensional limit for the WINDO of 
the graphics display 
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• GE — The upper dimensional limit for the WINDO of the 
graphics display 

• DCWN -- The lower dimensional limit for the WINDO of 
the graphics display 

• LECRT — The left dimensional limit for the VIEWPORT of 
the graphics display 

• REORT — ' The right dimensional limit for the VIEWPORT 
of the graphics display 

• OEORT — The upper dimensional limit of the VIEWPORT of 
the graphics display 

• DEORT — The lower dimensional limit for the VIEWPORT 
of the graphics display 

H. MODULE COMPOSITION AND CAPABILITIES 

The following sections of the chapter will address the 
general ccmposition and capability of each of the modules in 
this program. Within the discussion of each module, a 

brief description of the purpose of each subroutine within 
that module will be presented. This section is intended to 
be utilized in conjunction with the DSS computer program. 

1 . MAIN Module 

The MAIN module is the program unit which serves as 
the substructure upon which the remainder of the system is 
formed. The module is oriented around a BLOCK IF construc- 
tion which discriminates among the options (system modules) 
presented. 

2 • EUILD Module 

The 30ILD module of this program allows the user to 
build a local battle group database composed of ships which 
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the user designates. Additionally, this module functions 
as the point from which the user can INSERT or DELETE a ship 
from the battle group. The BUILD subroutine will differen- 
tiate between the user’s desires to develop the database for 
an entire force, or make individual changes to an existing 
structure, through the use LOGICAL IF and BLOCK IF construc- 
tions. There are two parameters which are required by the 
BUILD subroutine. The first (SEXIST), is a logical vari- 
able which flags the existence of a current battle group 
database. The seccnd (FIESTC), is again, a logical vari- 
able which is changed in the subroutine to indicate that 
this module has been called. The system requires that this 
module be called prior to operations in any other module 
with the exception of the DATAEASE module, discussed later. 
Within the EUILD Module, the numbers and names of the battle 
group ships, as well as their positions are determined. 
The search for the ship record in a master database is 
accomplished through the SEARCH subroutine, organic to this 
module. BUILD will also call the MANUAL subroutine, 

utilized for manual input of a ship' s database if the ship 
cannot be located in the master database. Finally, from 
this module, the CWC organization can be developed through 
the use of the CWC subroutine, organic to the BUILD module. 

a. Position Subroutine 



This subroutine is utilized by several of ohe 
system modules to input, change, and display the positions 
of the ships in the force. There are four entry points 

into this subroutine, controlled by a COMPUTED GOTO 
construction. These entry points, specified by the param- 
eter ’'TARGET" are BUILD module battle group Initialization 
(1) , BUILD module I KSERT function (2), STATUS module (3), 
and SENSCR module (U). This subroutine allows for 

specification of coordinate system, polar or cartesian. 



the 

and 



the position identification of each ship. Additionally, 
this subroutine develops the basic parameters upon which the 
graphics coordinate system is computed. This is done 

through the use of the PLOT? (polar) or PLOTC (cartesian) 
subroutines in the SENSOR module. 

t. cwc Subroutine 



This subroutine allows for the initial estab- 
lishment of the CWC organization as well as future display 
or component changes. The design of this subroutine is 
oriented around two COMPUTED GOTO constructions. The first 
differentiates between which module called the subroutine, 
Euild module CWC organization initialization (1), STATUS 
module Display cpticn (2) , or the STATUS module Change 

option (3) . The second COMPUTED GOTO construction is 

utilized tc orchestrate movement through the components of 
the eight (8) warfare comma nders/coor dinators in the organi- 
zation. A Icey feature in the operations of this subroutine 
is the elimination cf redundancy in the identification of 
organizations and embarked units. The pregram will attempt 
to match an input the user makes to any of those already 

input. When a match occurs, say in the naming of an 

embarked unit, the program assumes the value will remain as 
previously specified and will not query the user tc repeat 
the input. 

c. SEARCH Subroutine 



This subroutine will search the master database 
(FOR0 11. EAT) for the records associated with the named 
ships, and extract the appropriate record. This subroutine 

will alsc use the MATCH subroutine to allow the user to 
input a short form name for ship, convert it to long form, 
and reinitiate the search. 
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d. MATCH Subroutine 



This subroutine will attempt to match a short 
form name of a ship through the use of file FOR012.DAT. 

3 . STATUS Module 

The STATUS module in the Decision Support System 
allows the user to change an element in a particular ship's 
database record, change force positions, or change an 
element cf the CWC organization. Additionally, this module 
provides the vehicle whereby the user can display to the 
terminal screen, the positions of the force, as well as the 
names cf the units with specific weapons capabilities. 
This module is designed to operate without the use of 
computer graphics. The functioning of this module is 
oriented around the interpretation of a thirty four (34) 
character command string, which is segmented through the use 
cf the ENCODE fortran extension, discussed earlier. Each 
command string is broken into three character variables 
which respectively address, the major module options, data- 
base component to which this option is to be applied, and 
finally, the display or category specifier. Once the 
command string has been broken into the appropriate 
segments, the module utilizes BLOCK I? constructions to 
discriminate between the various segments. The STATUS 
subroutine comprises the largest portion of this module. 

a. DISDAT Subroutine 

Organic tc the STATUS module, the DISDAT subrou- 
tine provides the framework upon which the specific equip- 
ment names and associated ranges are translated from the 
codes utilized in the program databases. The operations of 
this subroutine are oriented around two general groupings of 
COMPUTED GOTO constructions. The first differentiates 



between the calling subroutines and directs program func- 
tions in either an equipment display or nomenclature/range 
display direction. While this subroutine is principally 

used ty the STATUS module, it does provide the terminal 
screen displays of specific equipments utilized by the 
SENS 05 and WEAPONS modules. 

4. COM NS Module 

The communications module is designed to accomplish 
two objectives. The first funczion is to manage the 
numbers of available radios onboard a ship for comparison 
with the installed capability. Second, this module will 

display the participants of a specified communications 
circuit on the graphics monitor. The query/response 

sequencing is accomplished through the use of menus from 
which a number entry is required to specify a desired 
option. Unlike tie SENSOR and WEAPONS modules, which 

cannot be operated if a graphics capability does not exist, 
the radio numbers management capabilities of this subroutine 
can be exercised without any graphics capability. 

5 . SENSOR Module 

This module is totally reliant upon computer 
graphics for its operations. The call from the MAIN module 
to this module is mads through a graphics control subroutine 
discussed later. This is the reason than the SENSOR module 
cannot be operated without a computer graphics capability. 
Within this module, the user can generate displays of the 
coverage areas of specified force sensors. The identifica- 
tion cf the specific sensor is made in a manner similar to 
that used in the STATUS module. The command string for 
this module is allocated 34 characters in length, and is 
comprised cf two components which are separated, and 
converted tc character representation. This is 
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accomplished through the use of the ENCODE Fortran exten- 
sion. Once the segments cr the command string are identi- 
fied, a BLOCK IF construction is utilized to direct the 
program flew through the various options. There are 

rumercus calls to EI-3000 unique subroutines within this 
module; however, they will not be discussed. 

a. PLOTF and FLOTC Subroutines 

While organic to the SENSOR module, these 
subroutines are principally utilized by the POSITION capa- 
bility of the BUILD module. The PLOTP/PLOTC subroutines 
will translate the user's polar or cartesian positions for a 
unit into useable coordinates for the graphics displays. 
The PLOTP subroutine uses a trigonometric calculation to 
make this conversion, whereas the PLOTC subroutine utilizes 
a BLOCK IF construction which makes a comparison to the "ZZ" 
unit’s "base" position. 

b. AREA Subroutine 

The AREA subroutine is the principle program 
driver from which the coverage areas of the various force 
sensors and weapons are generated. This subroutine will 
cause the VIEWPORT tc be defined for the coverage display. 
Additionally, it will convert the name of a ship into an 
internal form useable by the graphics system, through the 
use of the NAME_CQN VEST subroutine. AREA will call the 

DISDAT subroutine in the STATUS module to obtain the range 
for the specific sensor or weapon system it is plotting. 
While organic to the SENSOR module, this subroutine is also 
utilized by the WEAPONS module. 

c. AS W_ ARE A Subroutine 

This subroutine is a derivative of the AREA 
subroutine discussed above. The reason for the 
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differentiation between these two capabilities is that the 
force ASW display features are more complex than those used 
in displaying the radar coverages. This is because with 
the A SW display, optional convergence zone capabilities must 
be identified, matched to the sonars capable, which are 
further matched to those ships which have those sonars. 
Similar to the AREA subroutine, ASW_ARZA will establish the 
graphics VIEWPORT, convert the name of the ship into useable 
graphics fcrm, and access the range of the specific equip- 
ments through the DISCAT subroutine. 

d. Sensor Display — Title Generation 

The generation of the titles for the various 
display options in the SENSOR module is discussed collec- 
tively for all the module options. The following subrou- 
tines are used to place the display title on the graphics 
monitor: AIR_SEARCH, SURE ACE_SEARCH, F IR E_CO NTRO L , and 

SUB_SCREACE. The displays to which these subroutines 

correspond should be evident. The operations of each of 
these subroutines is identical. Each will establish a 
secondary VIEWPORT and WIN DO at the bottom cf the monitor, 
and will display the text primitives reflective of the 
information shown on the graphics plot. 

e. CZ_Z ONE Subroutine 

The function of this subroutine is to ascertain 
first, whether convergence zone sonar propaga tiers exist, 
and second, if they do, does the unit being displayed have a 
sonar capable of operating in this mode. The determination 
cf the existence of the propagation mode is done through a 
YES/NC query which establishes the value of a logical vari- 
able which is passed to the subroutine. Once determined, a 
COMPUTED GOTO construction, through the comparison with the 
coded scnar type onboard the unit concerned, generates a 
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logical variable "CCKVERG," which keys the display of the 
second coverage zone cn the ASW sonar display. 

6 . SEA SONS Module 

As its name implies, this module is utilized to 
display the coverage areas of the force weapons systems. 
Like the SENSOR module, WEAEONS is totally reliant on a 
graphics capability and is invoked from the MAIN module 
through a graphics control sequence. The module operates 
from a master menu where the user selects a specific weapon 
capability to be displayed. The lengthy command strings 
utilized in earlier ircdules dc not apply to WEAPONS. The 
module functions through the use of a BLOCK IF construction 
discriminating between the various weapons capabilities. 
WEAPONS uses self-contained program code for the generation 
cf all available displays. This code is identical to that 
used in the SENSOR module, but additionally, allows for the 
display cf multiple capabilities simultaneously, for example 
TOMAHAWK and HARPOON, or MISSILE and GUN. 

a. WEA?CNS_LABEL Subroutine 

As the name implies, this subroutine is designed 
to generate the labels for the coverage displays selected in 
the WEAPONS module. A BLOCK I? construction is used to 
create the appropriate label based on the capability being 
displayed. 

b. ASW_WEAPS Subroutine 

This subroutine displays the coverages for the 
force ASW weapons systems. The subroutine will assemble 
and display a coverage view reflective of each unit's heli- 
copter, ASW-Rocket, and torpedo capabilities. Each of 

these capabilities are color coded in the view. 
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* EAT ABASE Module 

This module will display to the terminal screen, the 
names and hull numbers of the ships in tae master database, 
grouped according to ship type. This module is operated 
through the use of a menu from which an identification 
number corresponding to the desired ship type is selected. 
The module then uses a COMPUTED GOTO construction to effect 
the computation of the key value and key field length neces- 
sary for accessing the appropriate records in the master 
database . 

8. SAVE Module 

The purpose of this module is to store the developed 
battle group database prior to a session termination, should 
the user so desire. This module will extract the database 
values, and create the three files discussed earlier, 
FORO C 7. EAT, FOR008.DAT, and FOR009.DAT. Once these files 
are created, the module will issue the FORTRAN STOP command, 
thereby terminating the session. Designed into the schema 
of the DSS is a program initiated automatic save of the 
tattle croup database after initialization in the BUILD 
nodule. This is dene only to provide a back-up should 
power be interrupted tut will not guarantee permanent reten- 
tion of the database should the user terminate his/her 
session with a STOP command from the MAIN module. 

9 • Major Su bro ut ines 
a. WAIT Subroutine 

This subroutine is incorporated into every 
module to allow the user to pause and take seme time 
reviewing the displayed information. Its construction is 

simply providing instructions to "Press return," and a READ 
statement which looks for an A1 formatted variable. 
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MANUAL Subroutine 



This subroutine is lengthy. It has been 

designed tc accomplish two major functions. First, should 

a ship in the battle group net reside in the master data- 
base, this subroutine allows that unit's capability record 
to be written to both the battle group database and the 
Hasten database (through the use of the DATA_CHANGE subrou- 
tine) . The construction of this subroutine is oriented 
around multiple queries and capability menus. The user 

need only select the appropriate capability from the menu tc 
include that capability on the ship in question. The 

MANUAL subroutine is also used by the STATUS module in 
changing an element cf a unit's database record. By desig- 
nation cf the desired capability to be changed, the appro- 
priate menu from this module is displayed for capability 
selection . 

c. CONTROL Subroutine 

The CONTPCL subroutine exists as the front and 
tack end program unit for all graphics displays. This 

subroutine makes the foundational calls to the required 
EI-3000 graphics routines. Additionally, this subroutine 
will determine the number of the desired graphics monitor to 
be used. This number is unique to the WARLAB at NPS. 

d. GRID Subroutine 

This subroutine overlays a cartesian coordinate 
grid on the displayed capability coverage display. The 
grid is scaled to the size of the plot in use, and its 
origin is offset commensurate with the cartesian position 
cf the unit at "ZZ." 
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THREAT Subroutine 



€. 



This subroutine creates a threat sector on top 
of a displayed capability coverage. The parameters for the 
generation of this sector, are the threat bearing and sector 
width, both provided by the user through a query dialogue 
with the system. 

f. HOVE Subroutine 

A major capability of this DSS is to allow rhe 
user to experiment wirh the coverage display creazed by 
moving a unit and observing the resultant effect on coverage 
that moving the ship's sensor/weapon would have. This 

subroutine parallels the main graphics modules by repeating 
their displays with a designated new position for a unit 
identified by the user. HOVE will create color-coded 

companion references to the old position as well as generate 
legends for evaluation of rhe new information being 
displayed. MOVE is only called from the SENSOR or WEAPONS 
modules . 

g. COMBAT Subroutine 

This subroutine is used to discriminate between 
surface combatant ship types and those non-combatant ship 
types. It is called from the MANUAL subroutine to elimi- 
nate the query for a database item not available to the ship 
type whose database record is being created. 

fc. LIST Subroutine 

The LIST subroutine simply utilizes the link 
list structure of the battle group database to display the 
rames of the units in the battle group. This subroutine is 
called whenever identification of a battle group unit is 
required, to assist the user in making the correct response. 
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LOCATE Subroutine 



This subroutine is utilized whenever a ship name 
from the battle group is the desired input to a query. 
LOCATE will, as its name implies, locate the ship within the 
link list structure, flag it "found," and pass the sequence 
number cf the ship back to the calling module. This 

subroutine is used throughout the program. 

j. NAM E_CON VERT Subroutine 

NAME_CONVEET will truncate the name of a ship 
for use in the graphics displays. This subroutine was 

devised to eliminate some of the clutter generated by the 
overlapping of the ship's names on the plots. However, its 
principle function is to convert the name of the ship, a 
character variable, into an internal form useable by the 
DI-30C0 text primitives. 

k. orient Subroutine 

This subroutine compares the coordinates of the 
ships graphics position with the quadrant in which it is in, 
and establishes the appropriate justification values for the 
JJUST call in the DI-E000 text output primitive. It basi- 
cally justifies the name to ensure it is pointing outward, 
away from the center cf the plot. 

l. DAT A_CH A NGE Subroutine 

DAT A_CH A NGE will accomplish one of two things. 
Eirst, it will write a manually developed ship database 
record to the master database. If the record already 

exists, this subroutine can be used no REWRITE (discussed 
earlier) the record should the user desire to make a capa- 
bility change permanent. 
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Now that the design of the program has been 
discussed, the next chapter of this thesis will address 
utili2ing the DSS. The User's Manual, as has already been 
mentioned, can be used as a reference, or as an instruction 
cn the operations of the DSS. The DSSdoes explain enough 
information that the reading of the User's Manual prior to 
conducting a session is not necessary. 
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III. DECISION SUPPORT SYSTEM USERJ.S MAN UAL 
A. INTBCDUCTION 

Welcome to the Battle Group Asset Management. Eecision 
Support System. New that you are ready to operate the 
system, the topics that follow will elaborate on rhe capa- 
bilities of the computer program. It is important to 

recognize at the outset that the complexity of your interac- 
tion with the system is NOT dependent on your having a 
Computer Science degree. You cannot "bomb" the program or 
accidentally damage any of the databases. Every request for 
information has been protected. Should you inadvertantly 

enter an incorrect character, the system will recognize that 
fact and ask you to reenter an acceptable value. This 
"error checking" alsc applies to the spelling of the names 
cf the ships you will be using. Your bywords should be 
"relax, I can't hurt anything." 

With an eye towards flexibility, the program can be 
operated either from the keyboard cf a computer terminal (in 
this case a VT-100/1C2), through voice recognition equip- 
ment, or through both simultaneously. Throughout this 
User's Manual, both the keyboard and the voice entry 
response options will be shown for each query. 

The database for this DSS in oriented to the Pacific 
Fleet. The 130 ships in the database comprise those PACFLT 
units whichcould be expected to be assigned to a battle 
group. While the service force units are included in the 
database, there are no amphibious ships included. 

If you were to group the program capabilities into two 
general categories, you would differentiate between these 
portiens which rely cn graphics software (DI-3000) unique 
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operations and those that don't. In general, the WEAPONS, 
SENSOR, and COMMS (f or the display Comm Net capability only) 
modules utilize computer graphics. If you do not have a 
graphics capability at the position where ycu are operating, 
then ycu cannot attempt to utilize these sections without 
causing an ERROR to cccur in the computer operating system. 
If this applies to you, simply do not attempt to use those 
sections . 

This User's Manual has been designed tc give ycu an 
exposure tc all the interactions you could expect to have 
with the system. In each example, you will be shown sample 
entries from both the keyboard (KB) and the voice recogni- 
tion (V 5 ) eguipment. The samples will be prefaced by KB or 
VR, as appropriate. Throughout the manual, when entering a 
command from the keyboard, you will be reguired to depress 
the CARRIAGE RETURN key (designated as <cr>) . Also, all 
commands from the keyboard MUST be in upper case. This 
differs somewhat from the operations using the voice recog- 
nition equipment. There will be some voice commands which 
already have incorporated into their output strings a 
CARRIAGE RETURN. There will be others, however, which 
require that the CARRIAGE RETURN command be input. 
Examples for the commands from the VR equipment will be very 
explicit, and will show the command "Carriage Return", if 
required. You can refer to Appendix A for a detailed 

explanation of the voice commands and applicable output 
strings. 

There will be occasions when the sample command is shewn 
within the text of a corresponding explanation. In these 
cases, the commands will be shown within quotes. If they 
are keyboard commands, DO NCT enter the quotes with the 
command, simply enter the portion of the example within the 
guotes. 
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While w e are on the topic of the CARRIAGE RETURN func- 
tion, the program will occasionally pause to allow you to 
examine the information on the screen. In these cases, 
there will appear at the bottom cf the screen the following 
state ment . 

*** PRESS CARRIAGE CONTROL TO CONTINUE *** 

To carry out this command, jou would enter the following: 

KB — <cr> 

VR — "Carriage Return" 

Finally, in most cases, the screen display for the 
queries we will be discussing will be shown in figures 
adjoining the explanation. There will be some occasions 
where the information displayed in a figure will not he in 
the exact format which you would see on the screen. This is 
due tc the fact that on the screen, 80 columns of informa- 
tion can be displayed, whereas in the figures, only 5U 
columns cf information can be shewn. The contents of the 
information in the figures will be complete, however its 
format will be different. In these cases, the reference to 
the applicable figure will have "(adjusted)" written after 
the figure number. An example of this would be when there 
are two large groups of information displayed side by side 
on the screen. In most cases, the figure representing the 
information would shew the same information in a single 
columnar fashion. This will become more clear tc you as 
ycu proceed through this manual, and operate the system. 
The next step is to cat going with the system. 

B. INITIATING THE PECGBAfl AT THE TERMINAL STATION 

legging on to a computer system and running a program 
are unique to the particular system. This Decision Support 
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System was developed on a VAX 11/780 computer system which 
had a R AMT EK color graphics capability associated with the 
computer operating system. The following procedures are 
unique tc this system. You may have to adapt them to ycur 
cwn system as appropriate. If you are also utilizing the 
ET-600 voice recognition equipment, you should lead the 
voice tape into the program tape reader at this time. 
Additionally, connect the T-600/VT- 100/102 and the VAX 
11/780 together using the interface designed for this 
purpose in the WARLAE. Now you are ready to go. 

If USEENAME is rot currently being displayed on the 
terminal screen, you should enter the following: 

KB — <cr> 

VR — "Carriage Return" 

1 * Ig gin/Prcgrair Initiati cn from the K eyboa rd 

Row that USEFKAMZ is being displayed, and you are 
operating from the keyboard, enter "DECISION <cr>". You 
will new see PASSWORD being displayed. (Obtain the pass- 

word from the WARLAB staff, and make the appropriate entry.) 
This display will end with the symbol $, and you are now 
ready tc run the program. Enter "RUN DSS <cr>", and you 
will begin to see tte displays from the Decision Support 
System. 

2. loqin/Pr egra a I niti ation throug h Voice Equi pmen t 

If you are operating with the voice equipment, enter 
"LOG DECISION ON." You will then see administrative infor- 
mation frem the operating system on the screen, followed by 
the symbol $. Now enter "RUN DSS PROGRAM," and you will 

begin tc see the displays from the Decision Support System. 
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C. PBOGFAM DATABASE IHITI AIIZ ATION 



As was discussed in Chapter I of this Decision Support 
System, you have the capability to work within the system 
and then terminate a session without loosing the information 
you have developed about your battle group. This is acne 
through the use of the SAVE module. When you commence a 
run/sessicn of the system, you will be presented with one of 
two series of queries for information. The one which is 
presented will depend on whether you have stored a battle 
group database from a previous session. We will lock at 
both versions. We will first examine the situation where 
there is a saved database and then look at one in which 
there is none. 



1 . Ea t tie G rou p F ormed Duri ng Pre viou s S ess i on 

If this is net your firsr session with the battle 
group database, then you will be initially shewn the 
existing composition of the battle group in the database. 
Figure 3.1 shows an example of the view you would see and 
reflects a five (5) ship battle group consisting of USS 
HIHI T Z , CSS PAUL F FCSTER, USS YORKTOWN, USS MERRILL, and 
USS GOIT2RRO already created. You will be queried as to 
whether or not you desire to continue with this battle 
group . 



a. Desire to Retain the Battle Group 

If you desire to retain the existing battle 
group database, then you would respond to this query as 
follows: 



KE — YES <cr> 

VE — " Affirmative” 
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A EATTLE GROUP DATAEASE HAS BEEN SAVED FROM A PREVIOUS 
SESSION. BATTLE GROUP COMPOSITION IS AS FOLLOWS: 

NIMITZ 

PAUL F FOSTER 
YORKTOWN 
MERRILL 
GUITARRO 

??? WOULD YOU LIKE TO CONTINUE WITH THIS DATABASE ? ?? 
(YES OR NO) 



Figure 3.1 Battle Group Already Formed. 

fc. Does Not Desire tc Retain the Battle Group 

If you <3c net desire to retain the existing 
tattle group database, then you would respond to the query 
as fellows: 

KB — NO <cr> 

VR — ’'Negative” 

The battle group database has now been erased and you will 
receive the following confirmation on the screen. 

THE DATAEASE HAS BEEN DELETED AND A NEW BATTLE GROUP MUST 
NOW EE ECILT. 

c. Error in Making Response 

Figure 3.2 shows the display you will receive if 
you inadvertantly make a mistake in entering the YES/NO 
response. Should this occur, simply reenter the response. 
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YCOB EESFONSE IS NCT REC CGN IZ SABLE AS AN ACCEPTABLE 
ANSWER. PLEASE ENTER YES OR NO. 



Figure 3. 2 Error in Making YES/NO Response. 

2 • Program Operation B ase 3 on Respons e 

Now that you bave made the decision as to whether or 
net you desire to retain a previously formed battle group, 
the system will do one of two things based on your decision. 
If your response was "Yes," the battle group database will 
be leaded into the operating section of the system. This 
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If you are initially forming a battle group, cr you 
have already decided on the disposition of the saved bartle 
group database, then the next query you will receive will be 
to deteriiine if you desire to review the Main Menu options, 
as shewn in Figure 3.3. 



If you desire to review the options, enter the 
following: 

KE — YES <cr > 

VR — "Affirmative" 
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??? SCOLD YOU LIKE TO REVIEW THE MAIN MENU OPTIONS ??? 
(YES/NO) 

! . . . . . - i 



Figute 3.3 Review of Main Menu Options Query. 

If you DO NOT desire to review the options enter the 
following: 

KB — NO <cr > 

VR — "Negative” 



a. Error in Making YES/NO Response 

If you inadvertantly make a mistake in entering 
the YES/NO response, you will see the view as shown in 
Figure 3.2, on the screen. If this occurs, simply reenter 
your response. 

4 • Pis tla v of Main Men u Option s 

If your response was to display the Main Menu 
Options, then you wculd have the display as shown in Figure 
3.4 (adjusted) and Figure 3.5 (adjusted) displayed on the 
screen. They are presented in two segments as the amount of 
information shown exceeds the capability imposed by the size 
cf the terminal screen. 



to 



When you are 
see the remainder 



ready to continue, 
cf then menu. 



enter the following 



KB — <cr> 

VR — "Carriage Return" 
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$$$$$$$$ * $$$ Jit#*:**#:*##*##**###*####*#########**####;*: 

* * 

* BATTLE GROUP ASSET MANAGEMENT * 

* DECISION SUEEORT SYSTEM * 

* * 

* MAIN MENU * 

* * 

* * 

* EUI1D ESTAELISH A LOCAL DATABASE BY IDENTIFY-* 

ING SPECIFIC BAITLE GROUP UNITS OR * 

* MAKE CHANGES TO EXISTING DATABASE EY * 

* ADDING OR DELETING A UNIT * 

$ $ 

* STATUS CALI OUT, DISPLAY, OR CHANGE BATTLE * 

* GROUE UNIT ECSITION, MISSION, EMBARKED * 

* COMMANDER, NUMBERS OF UHF/HF RADIOS, * 

* AND CHANGE IN ONBOARD SENSORS OF WE A- * 

* PONS SYSTEMS * 

$ # 

* CC M MS ESTAELISH PRIORITIZED NETS AND UNIT/ * 

* WARFARE CD E NET PARTICIPATION, GRAPHIC-* 

* ALLY DISPLAY NET OR MSG PATH * 

30C $ 

* (MENU CONTINUED) * 



*** PRESS CARRIAGE RETURN TO CONTINUE *** 




Figure 3.4 Main Menu Options. 



When you are ready to continue, enter the CARRIAGE 
RETURN command as described above. 

5. Sel ect ion of Main Menu Options 

At this point, you will be queried as tc which 
option you desire to utilize. This query is shown in Figure 

3.6. 

There is one caution which you should be aware of 
before you make your selection. If the battle group data- 
base esists and you have retained if, then you are free to 
select any of the Main Menu options shown in Figure 3.6. 
However, if this is the first session you are having with 
the system, and/or the battle group has net, as yet, been 
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* (MAIN MENU CCSTI.) * 

* SENSCR GRAPHICALLY DISPLAY UNI T/FORCE SENSOR * 

* COVERAGE AREAS AND EXPERIMENT WITH UNIT* 

* POS IT ION/S ENSOR COVERAGE AREA INTERPLAY* 

$ $ 

* WEAPONS GRAPHICALLY DISPLAY UNIT/FORCE WEAPONS * 

* COVEFAGE AREAS AND EXPERIMENT WITH UNIT* 

* POSITION/W EAPCNS SYSTEM COVERAGE AREA * 

* INTERPLAY. * 

* DATABASE DISPLAY THE SHIPS IN THE DATABASE BY * 

* TYPE 

$ $ 

* SAVE STOFE CURRENT BATTLE GROUP DATABASE IN * 

* A FILE AND THEN STOP THE PROGRAM * 

* # 

* STOP STOPS THE PROGRAM WITHOUT SAVING THE * 

* DATA INTO A FILE * 

*$**#$*$ *** # $ *** * * $ $ * I**#**#*:*##*:*#*## #***:«= 



*** PRESS CARRIAGE RETURN TO CONTINUE *** 



Figure 3. 5 Main Menu Options (conti) . 



? SELECT ONE OF TEE FOLLOWING: 

BUILD STATUS COMMS WEAPONS 

SAVE SENSOR STOP DATABASE 



IF YOU DESIRE TO REVIEW THE MAIN MENU OPTIONS ENTER 
"MENU" 




Figure 3.6 Selection of Main Menu Option. 



formed, ycur selections are restricted to either the 
DATABASE or BUILD options. The reason for this is that all 
ether system modules require seme or all cf the information 
contained in the database , which either must exist or 
initially be established in the BUILD module. Should you 
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accidentally attempt to enter ether than the DATAEASE or 
BUILE nodules in this case, you will receive the following 
warning and will be placed in the BUILD module. 

THERE ARE NC UNITS IN THE BATTLE GROUP DATAEASE AND YOU MUST 
FIRST ID3LC THE BATTLE GROUP. PLEASE ANSWER THE FOLLOWING 
QUESTIONS. 

For a more detailed explanation of the operations of 
the various modules in the system, refer to the appropriate 
section on the operations of that module. For example, 

information on the DATABASE module would be found in the 
section entitled DATABASE module Operations. If ycu are 
initially forming the tattle group, the the following short 
description of the functions of the 3UILD module will te of 
some value. 

a. 3UILD Module Functions During Battle Group 
Initialization 

When you are forming the battle group, the EUILD 
module will orchestrate the collection of data as follows: 

• Number of units in your battle group 

• Names of the units in your battle group 

• Name of the battle group unit to be designated as "ZZ" 
(for the purposes of this Decision Support System, a 
tattle group unit MUST he at "ZZ”) 

• Type of coordinate system used for stationing assign- 
ments (POLAR or CARTESIAN) 

• Positions of all units in the battle group 

• Composite Warfare Commander (CWC) Organization 

• Helicopter embarcation status for HELO capable units 
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Once you have identified the names of -he units 
in your tattle group, information concerning the onboard 
senscrs, weapons systems, and administrative information 
(e.g. Group Commander), unigue to each unit, is automati- 
cally obtained from a master database. This database 
contains in excess of 130 ships from which to choose. 
Should a unit in your battle group net be in this master 
database, you will be asked to provide the necessary infor- 
mation manually through the use of capability menus 
(discussed in BUILD Module Operations) provided on the 
terminal screen. Once this manual operation is complete, 
the unit will be permanently placed in the master database 
so that in the future, manual information insertion will not 
be necessary for that unit. 

6 • Mist ake in Re quest ! ng a Main Menu O pt ion 

Tc protect ycu should a mistake be made, there are 
parts of this system which will check your entries and if 
they are incorrect, advise you of such and allow you no make 
a correct entry. An example is contained in the following 
section. 



a. Mispellina of a Main Menu Option 

Should ycu accidentally mispell a request for a 
Main Menu Option, you will receive a warning as shewn in 
Eigure 3.7. 

To correct this mistake, simply reenter the 
desired option. Some examples are shown belcw. 

KB — 3UILD <cr> or REASONS <cr> or SENSOR <cr> 

VR — "Builc Module" or "Weapons Module" 
cr "Sensor Module" 
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YOOB SELECTION, AS ENTERED, DOES NOT CORRESPOND TC THE 
CHOICES AVAILABLE IN THE MAIN MENU. PLEASE ENTER ONE 
OF IHE FOLLOWING: 



BUILD STATUS COMMS WEAPONS 

SAVE SEKSCR STCP DATABASE 

MENU 



J 



Figure 3.7 Hispelling of a Main Menu Option. 

E. MAIN MODULE OPERATIONS 

The Main module, as an entity, may be transparent to 
you. It has been designed as a controller that organizes 
the flow cf your commands/desires between the other modules. 
Its principle function is to provide you a focal point from 

which you can easily move tc the other modules. You have 

already seen an example of this as you initialized your 

battle group database using the DATABASE and/or EUILD 

modules. 

As you move through the modules, when you elect to 
finish with that particular module, you will always be 
returned tc the Main module. This is signified by the query 
shown in Figure 3.3. The descriptions of each module, as 
shown in Figure 3.4 and Figure 3.5, are self explanatory. 
The remainder of this User’s Manual is organized into 
sections which address the operations cf each module. In 
every case, you will be walked through a session which exer- 
cises the capabilities of that module, as well as be shewn 
seme cf the possible pitfalls or problems you may encounter. 
There are two modules that require some emphasis at this 
point, as they will terminate a session in distinctly 
different fashions. These are the STOP and the SAVE 
modules. They will be discussed next. 
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£. "STOE" MODULE ANE "SAVE" MODULE OPERATIONS 

These two modules are discussed together, as they both 
result in the termination of a session in the Decision 
Support System. The SAVE module, however, will first file 
all the tattle croup information that you have developed 
before termination occurs. This contrasts to the func- 
tioning of the STOP module which terminates a session 
without filing any cf the developed information. 

Terminating a session with the STOP module will require you 
to fcim a new battle group at the beginning of your next 
system session. Let's briefly expand on the operations of 
these two mcdules. 

1 • f A VE Mo dule Cp erati ons 

The SAVE module has been designed to store the data- 
base fcr your battle croup when you desire to terminate ycur 
session. It is invoked from the query shown in Figure 3.6, 
as fellows: 

KE — SAVE <cr> 

VE — "Save Module" 

When you invoke this capability of the DSS, the ship 
names, capabilities, positions, administrative data, etc., 
which ycu have developed for ycur battle group, as well as 
the CfiC Organization, will all be snored fcr future use. 
Having terminated a session with this module, when ycu rein- 
itiate a DSS session, you will be initially be presented 
with the information shown in Figure 3.1. 

Session termination on the VAX 11/780 will be marked 
by the statement FCETRAN STOP followed by the symbol $ 
appearing on the screen. When this occurs, you can termi- 
nate your ESS session with the following command. 
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FE 

VB 



LCGO <cr> 
"Terminate'' 



Ycu are tow finished, and can turn the terminal and graphics 
(if applicable) off. 

2. STOP Module Operations 

The functioning of the STOP module is straightfo- 
ward. It will terminate your session without saving/ 
storing any of the information which you have developed. It 
is invoked from the guery shown in Figure 3.6, as follows: 

KE — STOP <cr > 

VB — "Step Module" 

If you have no future requirement for the data with 
which you have been working, then this is the capability 
that ycu should use to terminate your DSS session. Any 
information previously stored will be deleted when the STOP 
module is invoked. 

The pragmatics of a session termination when using 
the STOP module on the VAX 11/760 are identical tc those 
described in the section on the SAVE module Operations. 

3 • Pro gra m Init mated S AVE Fun ction 

There is nothing more frustrating to rhe experienced 
computer user, or intimidating to the inexperienced user 
than tc have the program "bomb," for no explainable reason. 
The reasons for this are, of course, more often than not, 
explainable. However, that doesn't restore the sometimes 

hours cf work which may have lead up to the incident. That 
may be hours of work which were lost. 

In an effort to alleviate such anxiety, and protect 
against a less of information, the Decision Support System 
has been designed tc perform a one-time automatic SAVE of 
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the information which you have entered. This will occur at 
the completion of your first establishment of the baffle 
group database in the BUILD module. You are not required 
to perform any keystroke or voice command to effect this 
SAVE. In fact, with the exception of a possible 1-2 second 
delay in refreshing the screen, it will be transparent to 
you. This capability is identical to that which you would 
use by invoking the SAVE module, with the exception that the 
session will NOT be terminated. In this manner, should a 
power failure or fluctuation cause the program to "tomb," 
you will net loose tie work you have done. When you reini- 
tiate the program, the information will appear as shown in 
Figure 3.1, just as if YOU had saved in. Invoking the STOP 
Module will erase this information before terminating your 
ISS session. 

F. E1TAEASE MODULE CEERATI CNS 

There could be two situations in which you may find 
yourself when using this decision support system. The 

first, and most pr edeminant , instance will be that you have 
a battle group formed and you enter the names of the units 
in that tattle group into the system. Transparent to you, 
the program will take those names and extract from a master 
database, the capabilities, administrative data, etc., 
attributable to those particular units. As was mentioned 
earlier, there are some 130 ships in the master database. 
So, ycu can see that all ships in the Navy are not there. 
Insertion of the name of a unit which is net in the database 
would require you to enter its database of information manu- 
ally. If you would like to confirm that one of your tattle 
group's units is in the master database prior to inserting 
its name in the BUILD module, you could invoke the DATABASE 
module and access tie particular ship type of the unit for 
which ycu are looking. 
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The second situation you nay find yourself in is that 
you are experimenting with theoretical battle group composi- 
tions, and would like to select from the list of available 
units the ships for your battle group. Again, invoking the 
EATAEASE module will allow you to view all of the units in 
the master database, in groupings of ship type, as you 
desire. 

1 • Inv okin g the E AT ABA S E M odul e 

fihen presentee with the query shewn in Figure 3.6, 
the EATAEASE module can be invoked as follows: 

K3 — DATABASE <cr> 

V R — "Database Module" 

This entry will move you from the Main module into 
the EATAEASE module ar.d you will be presented with the query 
shown in Figure 3.8 (adjusted). 



2. Se l ectin g a Shin T^£g O ctio n 

Figure 3.8 provides the menu for selection of the 
available ship types in the master database. To display 
the names and hull numbers of the units in a particular ship 
type grouping, simply enter the number corresponding to the 
ship type you desire. An example of this response is shewn 
below . 



KB — 1 <cr> or 

1 3 <cr> 

VR — "One" "Carriage Return" or "One" "Three" 

"Carriage Return" 
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*** * * ****** ******* ****** $*** *********** *************** 



* BATTLE GROUP ASSET MANAGEMENT * 

* DECISION SUPPORT SYSTEM * 

* * 

* * DATABASE MODULE * * 

* * 



*************** ********* ****************************** 

THIS MODULE ALLOWS YOU TC DISPLAY THE UNITS IN THE 
MASTER DATABASE AS CATEGORIZED BELOW. SELECT THE NUM- 
BER CORRESPONDING TO THE SHIP TYPE YOU DESIRE. 

1 - SUBMARINES (SSN) 

2 - AIRCRAET CARRIERS fCV/CVN) 

3 - GUIDED MISSILE CRUISERS (CG/CGN) 

4 - DESTROYERS (DD) 

5 - GUIDED MISSILE DESTROYERS (DEG) 

6 - FRIGATES (FF) 

7 - GUIDED MISSILE FRIGATES ( FFG) 

6 - BATTLESHIPS <BB) 

9 - REPLENISHMENT OILERS (AOR) 

10 - FAST COMBAT SUPPORT SHIPS ( AOE) 

11 - COMBAT STORES SHIPS (AFS) 

12 - AMMUNITION SHIPS (AE) 

13 - OILERS (AO) 




Figure 3.8 DATA EASE Module Selections. 



would 

would 



In this example, the ship type SUBMARINES 
be selected. Figure 3.9 is an example of 
see having selected the ship type SUBMARINES 



cr OILERS 
what you 
(SSN) . 



* SUBMARINES * 



PERMIT 
LCS ANGELES 
LA JOLLA 



SSN594 

SSN688 

SSN7Q1 



GUITARRO 

INDIANAPOLIS 



SSN665 

SSN697 



*** PRESS RETURN TC CONTINUE *** 



Figure 3.9 SUBMARINES in the Master Database. 
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If your selection had been in the latter example 
above, ycu would be selecting the OILER (AO) ship type, and 
Figure 3.10 shows the view you would get on the screen. 



* OILERS * 

CIMARRON AC177 WILLAMETTE A0180 

PLATTS AC 186 



*** PRESS RETORN TO CONTINUE *** 



i i 



Figure 3.10 OILERS in the Master Database. 



When you are through examining the ships in the ship 
type grouping you have selected, enter the following 
ccramand s : 

K3 — <cr> 

7 R — "Carriage Return" 

To allow you the opportunity to view another ship 
type, ycu will receive the following query. 

??? WOULD YOU LIKE TO SEE ANOTHER SHIP TYPE ??? 
(YES/NO) 

Ycur response to this query would be the following, 
as applicable 

KB — YES <cr > or NO <cr> 

VR -- "Affirmative" or "Negative" 

If your response is net to see another ship type, 
then ycu will be returned to the Main module. If you 
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desire tc see another ship type, you will be presented with 
the E ATAEAS E module menu (Figure 3.8). 

Should you inadvertantly make a mistake entering 
your YES/NC response, you will be presented with the 
following. 

PLEASE ENTER YES OR NO 

At that point, simply reenter your YES/NO response. 

a. Error in Selecting Ship Type From Menu 

Should you accidentally make an incorrect entry 
while making your ship type selection, yon will be presented 
with the following on the screen. 

YOOR SELECTION DOES NOT CORRESPOND TO THE MENU OPTIONS. 
YOU WILL HAVE TO REENTER. 

*** PRESS RETURN TO CONTINUE *** 

To continue, make the CARRIAGE RETURN command as 
described above, and you will be returned to the DATABASE 
module menu. 

G. BUIir HCDULE OPERATIONS 

While the MAIN module is the hub of activity between the 
modules of ths system, the BUIID module develops the founda- 
tion upon which the entire system will operate. Within the 
EUILD module, the composition of the battle group in deter- 
mined, unit positions assigned, and the Composite Warfare 
Commander (CWC) organization managed. There are twc 

differentiable segments to the BUILD module. They are 
oriented around whether a battle group database (previously 
specified by the user) already exists. 

When there is no battle group formed, you will first 
work within this module to identify the names of the battle 
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group units, their positions and helicopter embarcarior. 
status. Additionally, along the way, you will identify a 
unit which will function as ” ZZ" (Remember that this system 
requires a battle group unit be at "ZZ."), specify a coordi- 
nate system to be utilized, and identify the organizations 
which will function as warfare commanders. As was 

mentioned earlier, when you specify a unit’s name, its data- 
base is automatically obtained unless rhe ship dees net 
reside in the master database, in which case you would manu- 
ally enter that data. 

Cnee the battle group has teen formed, you would use the 

EUILE module to INSERT or DELETE a unit, or to REBUILD the 

entire battle group database. Whan you exercise the INSERT 
capability, you would go through the same sequence of 
gueries regarding the unit to be inserted as you did when 
initially forming the battle group. When you exercise the 
DELETE capability, as the name implies, you would be 
removing the information for the specified unit from the 

tattle group database. The REBUILD capability allows you 

to construct a completely new battle group database. 

In the following sections, we will move through the 
EUILE module and demonstrate the interactions you can antic- 
ipate having. The EUILD module is invoked from the query 
shown in Figure 3.6, as follows. 

KB — EUILD <cr > 

VR -- ” Build Module” 

We will rew go through the operations of rhis module. 

1 . Ini tia lly For min g a Battle Group 

For the purposes of our example, we will operate 
with a three (3) ship battle group consisting of USS CARL 
VINSON (CVN-70) , USS PAUL F FOSTER (DD-964) , and USS 
CALIFORNIA (CGN- 36) (a unit not in the master database). 
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The first view which you will be shown is an explanation of 
the functions of the module, and is shown in Figure 3.11 
(adjusted). This view reiterates much of what we have 
already discussed abcut the BUILD module. 



BATTIE GROUP ASSET MANAGEMENT 
DECISION SUPPORT SYSTEM 

3UILD MODULE 

THIS MODULE WILL ALLOW YOU TO BUILD A DATABASE OF THE 
CAPABILITIES OF THE UNITS IN YOUR BATTLE GROUP. THESE 
CAPABILITIES WILL INCLUDE ALL SENSOR AND WEAPONS SYS- 
TEMS CNBCARD, AS SELL AS NUMBERS OF UHF/HF RADIOS ON- 
ECABE. THIS DATA HAS BEEN COMPILED FOR ALL PACIFIC 
FLEET UNITS. YOU WILL BE ASKED TO PROVIDE THE NAME OF 
EACH UNIT, AND THE COMPUTER WILL LOCATE THE REQUIRED 
DATA FOR THAT UNIT AUTOMATICALLY. SHOULD A UNIT NOT 
EE IN THIS MASTER EATA3ASS, YOU WILL BE SO INFORMED 
AND TEEN YOU WILL EE ASKED TC PROVIDE THE NECESSARY 
INFORMATION IN A "PROMPT /ANSWER” FORMAT. YOU WILL NCW 
BE ASKED FOR THE NUMBER CF UNITS IN YOUR BATTLE GROUP, 
AND TEEN THE NAME CF EACH UNIT. PLEASE ANSWER THE 
QUESTIONS AS THEY APPEAR. 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.11 BUILD Module Discussion. 



When you ere ready to continue, you would enter the 
following : 



KB — <cr> 

VR — ’’Carriage Renum" 

The next query you will receive is for the number of ships 
in your tattle group. 
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a. Establishing the Number of Ships in Battle Group 

This will be the only tima you will be asked for 
the total number of ships in your battle group. As you 

operate the system, once this value has been initially 
entered, it will be automatically kept current by the 
system. the query for the number of ships in the battle 
group is shewn in Figure 3. 12 (adjusted) . 



??? HCK MANY SURFACE COMEATANTS, CARRIER (S) , SUBMAR- 
INER) ARE IN YOUR BATTLE GROUP ??? 

(ENTER UP TO A MAXIMUM OF 25 SHIPS) 



Figure 3. 12 Query — limber of Ships in Battle Group. 



As the query shows, the range fer the required input is 1 - 
25 ships. Since cur sample battle group has three (3) 
ships, we would enter the following. 

KB -- 3 <cr> 

V R -- "Three” "Carriage Return" 

If you had fen (10) ships in your battle group, your entry 
would lock like this. 

KE — 10 <cr > 

VR -- "One" "Zero" "Carriage Return" 

If you inadvertantly make a misrake in making this entry, 
you would see the following on the screen. 

THERE HAS EEEN AN ERROR IN INPUTTING THE NUMBER ON UNITS IN 
YOUR EATTLE GROUP. YOU WILL HAVE TO REENTER THE NUMEER. 
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*** PBESS RETURN TO CONTINUE *** 



When ycu axe ready tc continue, and reenter your number of 
ships, enter "RETURN, "as described above, and you will again 
be given the query shewn in Figure 3.12. 

After you have successfully entered the number 
cf ships in your battle group, you will be given a confirma- 
tion cf your entry, as shown in Figure 3.13. The statement 
would shew the number of ships ycu entered, and ask ycu to 
confirm that the number is correct. In our example, the 
number of ships entered was three (3) . 



TEZRE IS/ARE 3 UNIT (S) IN YOUR EATTLE GROUP. 
??? IS THIS CORRECT (YES/NO) ??? 



Figure 3. 13 Eattle Grcup Size Confirmation. 



You should acknowledge the confirmation with the following 
response, as appropriate. 

KE -- YES <cr > or NO <cr> 

VR — " A f f irmat i ve" or "Negative" 

Should ycu make an error entering your YES/NO response, you 
will see the following on the screen. 

PLEASE ENTER YES OR NO 

Simply reenter your YES/NO response as shown above. Should 
the number shown in the confirmation statement be incorrect, 
you will again be given the query shown in Figure 3.12, and 
the sequence of events described above will be repeated. 
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t. Ship Name Entry 



Once you have identified the number of ships in 
your tattle group, the next step will be to enter their 
names. Following your confirmation that the number of 
ships in the battle group is correct, the explanation shewn 
in Figure 3.14 (adjusted) will be displayed. 



YOU WILL NOW BE ASKED TO ENTER THE NAMES OF THE UNITS 
IN YOUR EATTLE GROUP. A PROMPT "SHI? NAME" WILL AP- 
PEAR AFTER WHICH YOU SHOULD ENTER THE NAME OF A UNIT. 
REFER TO YOUR USER’S MANUAL UNDER THE "SHIP NAME" LIS- 
TINGS FOR THE FORMATS OF THE KEYBOARD OR VOICE ENTRIES 
FCF AVAILABLE SHIPS. FOR KEY30ARD ENTRIES, NAMES ARE 
LIMITED TO 19 CHARACTERS WITHOUT ANY COMMAS OR PERI- 
ODS. SPACES EETWEEN WORDS COUNT AS CHARACTERS. IF 
TEE NAME OF THE BATTLE GROUP UNIT DOES NOT APPEAR IN 
THE USER’S MANUAL, THEN KEYECARD ENTRY WILL BE RE- 
QUIRED, AND VOICE INPUT WILL NOT WORK. 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.14 Ship Name Entry Explanation. 



When ycu are ready tc continue and enter the names of the 
ships in ycur battle group, enrer "RETURN," as described 
earlier, and you will receive a "SHIP NAME ?" prompt. 

You will receive this prompt a number of times 
which corresponds to the number cf ships ycu indicated were 
in ycur battle group. You should note than if you are 
entering the information from rhe keyboard, you are limited 
to nineteen (19) characters for a ship's name, including 
spaces. The length cf the names of the ships ycu can enter 
by voice have already been matched to this reguirement. 
Also note that if the name cf a ship in your battle group is 
not in the master database (as you could confirm in the 
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DATABASE module discussed earlier) , voice entry is not 
possible. In this situation, the name of the ship would 
have to he entered from the keyboard. If you did nor check 
the names cf your ships in the DATABASE module, you can 
confirm the names in Appendix A. If the name of a ship is 
shown in Appendix A, then it will be in the master database. 

For our example battle group, the prompts and 
applicable responses would be as follows: 

SHIP NAME ? 



KB — VINSON <cr> 
VR — "VINSON" 

SHIP NAME ? 

KB — FOSTER <cr> 

VR — "FOSTER" 

SHIP NAME ? 



or CARL VINSON <cr> 

cr "CARL VINSON" 

or PAUL F FOSTER <cr> 

or "PAUL F FOSTER" 



KB — CALIFORNIA <cr> 

VR — (not possible as USS CALIFORNIA is net in the 
uas-ei database) 

Should you make an error in entering the name of 
a ship, you will see the following on the screen. 
Usually, the only mistake you can make is to enter a name 
longer than nineteen (19) characters. 



YOUR INPUT WAS NOT ACCEPTED BY THE COMPUTER. YOU WILL HAVE 
TO REENTER THE SHIP'S NAME. 



*** PRESS RETURN TO CONTINUE *** 

When you are ready, you continue as described earlier, and 
the "SHIP NAME ?" prompt will appear. You then reenter 

the name of the ship. 
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Now that you have entered the names of the ships 
in your tattle group, you will be shown the composition of 
the tattle group that you have entered into the system. 
This confirmation check is very important. The master 
database is keyed to the names of the ships, and if the 
spelling of the names is not exact, then the database will 
treat the name as if it were net there, and the user will be 
prompted tc build the database entries for that unit as 
explained later. The system has been programmed tc recog- 
nize seme short form names of ships (e.g. FOSTER for PAUL F 
FOSTER, ox VINSON for CARL VINSON), but you can never go 
wrong by using the full ship name. Always be sure that you 
include spaces where they would be appropriate. Figure 
3.15 (adjusted) shows the composition of our example tattle 
group for our confirmation. 



HERE IS A LIST OF THE SHIPS YOU HAVE ENTERED AS YOUR 
EATTLE GROUP. PLEASE CHECK THE LIST FOR ACCURACY AND 
SPELLING. 

1 CARI VINSON 2 PAUL F FOSTER 

3 CAL 3E0FNIA 



PLEASE ENSURE THAT THE AEOVE NAMES ARE CORRECTLY 
SPELLED. IF THEY ARE, PRESS CARRIAGE RETURN, OTHER- 
WISE, ENTER THE NUMBER OF AN INCORRECT ENTRY AND EN- 
TER TEE CORRECT SPELLING AFTER THE "SHIP NAME ?" 
PROMPT. 






Figure 3. 15 Battle Group Name Listing. 



As is directed in Figure 3.15, if the entries 
are correct, enter "RETURN," (as described earlier) , or if 
not, the number corresponding to the incorrect ship name. 
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As shewn in this case, the list is correct, and we should 
enter RETURN. As an example, however, let us assume that 
CARL VINSCN was accident ial ly spelled CARL VINSAN. Since 
this is incorrect, you would enter the following. 

K 3 — 1 <cr> 

VR -- "One” "Carriage Return" 

You would new see the view shown in Figure 3.16. 




figure 3. 16 Correction to Ship Name. 



Notice that Figure 3. 16 shows the incorrect 
spelling fer the ship. You would now enter the correct 
spelling for the VINSCN (again, subject to the nineteen (19) 

character limit if from the keyboard) , as shown in the 

following example. 

KB — CARL VINSON <cr> 

VR — "CARL VINSON" 

Once the correction to the ship name has bean 
made, ycu will again be shown the view in Figure 3.15 to 
confirm the names cf the battle group units. For tha 

purposes cf our example, we will assume that it is now 

correct, and you should enter "RETURN," (as described 
earlier) . 

Should ycu make an error in entering a CARRIAGE 
RETURN cr the number of the ship that is incorrectly 
spelled, ycu would see the following on the screen, after 
which ycu can make the correct entry. 
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PRESS CARRIAGE RETURN IF THE LIST IS CORRECT , OR IF NOT , THE 
APPRCFRI ATE TWO DIGIT NUMBER 

Since the listing was correct, and ycu entered 
CARRIAGE RETURN, ycu will new see an explanation of the 
operations of the system with respect to the units in your 
battle gicup. This information is shown in Figure 3. 17. 
The display of this view also signifies that the master 
database is being searched for your units and their capabil- 
ities are being filed in a battle group database. The 

units net in the master database will be "flagged’' for 
manual insertion of their capabilities information. 



THE CATAEASE IS BEING SEARCH TO ASSEMBLE THE INFORMA- 
TION ECR YOUR BATTLE GROUP. PLEASE WAIT FOR AN ACK- 
NOWLEDGEMENT CF SEARCH COMPLETION PRIOR TO ENTERING 
ANY EUETEER DATA. YOU WILL BE TOLD IF THERE IS A PRO- 
BLEM IN LOCATING ANYTHING AEOUT YOUR UNITS. 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.17 Master Database Search in Progress. 



When ycu are ready tc continue, enter CARRIAGE RETURN (as 
described earlier) . You should notice a shorn delay in the 
screen refreshing as the master database is searched. If 
there is nc difficulty in searching the master database, 
then the next query you should see is to determine which 
unit will function as "ZZ." (This is discussed under Battle 
Group Position Determination.) If a ship requires manual 
capability information entry, then you will be so informed. 
Manual capability insertion is the subject of the next 



c. Manual Entry of Capabil it ias 

As we designed into our example battle group, 
DSS CALIFORNIA was net a unit in the master database. That 
being the case, ycu would see the information shown in 
Figure 3.18, indicating the units not in the master data- 
base, and requiring iranual capabiiitiy entry. 



TEE FOLLOWING UNITS WERE NOT IN THE MASTER DATABASE 
ANE WILL REQUIRE MANUAL DATA ENTRY. 



C A Ilf CRN IA 



SINCE THESE UNITS ARE NO 
INFORMATION REGARDING TH 
MANUALLY. THIS WILL REQ 
OF SENSORS AND WEAEONS S 
PRESENTEE EQUIPMENT SELE 
THE FCRM OF EASY TC USE 
FIVE MINUTES PER SHIP TO 
CRITICAL FOR THE CPERATI 
THIS EEC ISIO N SUPPORT SY 
CONTINUE, ENTER "YES," A 



T IN THE MASTER DATABASE. THE 
EM WILL HAVE TO EE ENTERED 
UIRE A KNOWLEDGE OF THE TYPE 
YSTEMS ONBOARD. 

CTI0N/A5 SIGN MEN T 
MENUS. IT TAKES 
ENTER THE DATA. 

CN CF THE OTHER 



YOU WILL BE 
OPTIONS IN 
APPROXIMATELY 
THIS DATA IS 
MODULES OF 



STEM. WHEN YOU ARE READY TO 
ND THE FIRST MENU WILL APPEAR. 



Figure 3.18 Units Not in the Master Database. 



You must enter this information for CALIFORNIA in order for 
the system database tc be complete. when ycu are ready to 
contirue, enter the following: 



KB 

VR 



YES <cr> 
"Affirmative" 



If ycu should enter anything other than the YES response, 
you will see the following. 



PIEASE ENTER YES OR NO 
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fchen you are ready, and have the required information, enter 
YES as shewn above. Wa will now follow the sequencing of 
manual data entry for OSS C ALIFOENI A. 

(1) Hull Number Determinatio n. Determination 
of the ship’s hull number, particularly with respect to the 
ship type, is very important to the system. The query for 
this information is shown in Figure 3.19. 



FOE CALIFORNIA 1 

??? WHAT IS HER HULL NUMBER ??? (MAXIMUM CF SIX CHAE- | 
ACTERS E.G. SSN638, DD980, FF1075, ETC.) | 



Figure 3. 19 Query — Hull Number Determination. 



This entr y from the keyboard is self- 
explanatory, remembering that there can be NO blanks or 
spaces in the hull number as shown in the examples. Figure 
3.20 shows the keyboard entry for CALIFORNIA as well as 
examples for other ship types. 



CALIFORNIA 


CGN36 


<cr> 


SUBMARINE 


SSN688 


<cr > 


FRIGATE 


FF1078 


<cr > 


OILER 


AO 1 077 


<cr > 



Figure 3.20 Hull Number Entry From the Keyboard. 
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The keyboard entries contrast tc these 
tads by voice. The examples shown in Table I are extracts 
of the information contained in Appendix A. 



TABLE I 

Ship Type by Voice 



SEIE TYFE 
SSN 

cv 

CVN 

CG 

CGN 

EC 

DDG 

FF 

FFG 

SOE 

AOB 

EE 

AFS 

AO 



SAMPLE VOICE COMMAND 

"S ubmarine " 

"Aircraft Carrier" 

"Nuclear Aircraft Carrier" 
"Guided Missile Cruiser" 
"Nuclear Guided 
"D est rcyer" 

"Guided Missile 
"F rigate" 

"Guided Missile 
"Fast Combat Support Ship" 
"Replenishment Oiler" 

"3 attleship" 

"Combat Stores Shin" 

"Fleet Oiler" 



Missile Cruiser" 
Destroy er" 






riaate' 



2.21 shews 
CALI FCENIA. 
response, y 



For the 
the voice 
Should you 
cu will s e s the 



purposes of our 
input for the 
make an error i 
view in Figure 



n 

3 



example, Figure 
hull number of 
entering either 
0 2 



"Nuclear Guidec Missile Cruiser" "Three" "Six" 
"Carriage Return" 



Figure 3.21 Hull Number Entry by Voice. 
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YOU WILL HAVE TO EEENTER THIS VALUE. 



figure 3.22 Response Error Identification. 

(2) Gro uc Ass ign ment Determination . One of 
the administrative elements of the unit's database is its 
Cruiser-Cestro ye r/Carriar Group assignment. This informa- 
tion in the system is not applicable to either Submarines or 
Service Force units, therefore, if the ship type indicated 
in the hull number cf a unit identifies it as one cf these 
types, this query will not be presented. For our example, 
the query for the group assignment is shown in Figure 3.23. 



FOB CALIFORNIA 

??? TC WHICH CRUDESGRU OE CARGEU IS SHE ASSIGNED ??? 
( 1, 3, 5,7, or 9 (HIDPAC) ) 



Figure 3.23 Query - Group Assignment. 



While the query in Figure 3.23 shews 
"9 (MIEP AC) , " as a group option, only the "9" is the appro- 
priate response if applicable. Your response should be the 

appropriate CRUDESGRC/CARGR U number. If CALIFORNIA were 
assigned tc CRUDESGRU 3, the following is the format of the 
correct entry. 

KB — 3 <cr> 

VR — "Three" "Carriage Return" 
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Should an error occur in making your response, the following 
will te displayed on the screen. 

LIMIT YOUE ANSWEE TC 1, 3, 5, 7, or 9 
*** PRESS RETORN TC CONTINUE *** 

When ready, continue as discussed in earlier examples. 

(3) Squa dron Ass ignment Deter minat ion. With 
all destroyer and frigate ship types (as indicated in the 
hull number) , the next query addresses the destroyer 
squadron assignment. This query will not be presented for 
non DE/DEG/EF/FFG ship types. The query is shown in Figure 
3.24. 

Your response to this query can be any one 
or two digit number reflective of the unit's DESRON assign- 
ment. For our example battle group unit, CALIFORNIA, you 
would not get this query, as the CALIFORNIA is a CGN , a unit 
net assigned to a DESEON. A sample response to this query 
for PAUL E EOSTER would be as follows. 



FOE PAUL F FOSTER 

?? 10 WHICH DESRON IS SHE ASSIGNED (IF APPLICABLE) ?? 




Figure 3.24 Squadron Assignment Determination. 



KE — 23 <cr> 

VE — "Tsc" "Three" "Carriage Return" 
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Should you make an error in entering your DESRON assignment, 
you will see the following: 

YCU WILL HAVE TC REENTER THE DESRON ASSIGNMENT 
*** PRESS RETURN TO CONTINUE *** 

When you are ready, enter CARRIAGE RETURN, 
than the query shown in Figure 3.24 will be presented, and 
you should reenter ycur response. 

(4) Prim ary /Se c onda ry Mis si le S ystem 

Det e rmi na tion . The determination of the 

primary anc secondary missile system capabilities are 
addressed together. Recognize that a ship may have both a 
primary and secondary system, only a primary system, cr no 
missile system capability at all. Figure 3.25 (adjusted) 
shows the available missile system options. The following 
will precede the menu for determination of the ship's 
primary missile system capability. We will use CALIFORNIA 
for the sample. 

If the ship has no missile system, then 
you would select "NOT APPLICABLE," entering "0". with no 
primary missile system indicated, you will not be asked 
about any secondary capability. Should you indicate that 

the ship dees have a primary missile system, then ycu would 
again receive the query shown in Figure 3.25. This time, 
the query would be prefaced with the following statements. 

FOR CALIiCFNIA 

??? WHAT IS HER SECONEARY MISSILE SYSTEM (IF APPLICABLE) ??? 

In all cases, when responding tc these 
queries, ycu would indicate the appropriate system for that 
ship by entering the number tc the left of that capability. 
Fcr CALIFCF NIA , which has cnly an SMI -MR system, we would 
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FOB CALIFORNIA 

??? WHAT IS HER PRIMARY MISSILE SYSTEM ??? 

* MISSILE SYSTEM OPTIONS * 

0 NOT APPLICABLE 

1 NATO SEASPARROW MISSILE SYSTEM (RIM-7) 

2 STANDARD MISSILE SYSTEM (SM1-ER) (RIM-67) 

3 BASIC POIKT DEFENSE MISSILE SYSTEM (RIM- 7) 

4 STANDARD MISSILE SYSTEM (SM2-MR) (RIM-66C) 

5 STANDARD MISSILE SYSTEM (SM1-MR) (RIM-66E) 

6 STANDARD MISSILE SYSTEM (SM2-ER) (RIM-67E) 

SELECT 0, 1 , 2, 3, 4 r 5 , cr 6 



Eigure 3.25 Query Menu - Missile System Options. 

respond to the query regarding the primary missile system as 
follows . 

KB — 5 <cr> 

VR -- "Five” "Carriage Return” 

Since we indicated that CALIFORNIA has a 
primary irissils system, then the query for her secondary 
missile system capability will be presented. CALIFORNIA has 
no secondary missile system, therefore, the response would 
be as fellows. 

KB — 0 <cr> 

VR -- "Zero” "Carriage Return" 

Should an error occur in entering e it her 
of these values (pri uary/seccndary capability), you will see 
the following. 

YCD M C ST LIMIT YOUR CHOICES TO 0, 1, 2, 3, 4, 5, or 6 

*** PRESS RETURN TO CONTINUE *** 
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Continue as discussed earlier, and the appropriate preface 
(primary/secondary) along with the missile system options 
will appear. Make your selection as demonstrated. 

(5) Ha rpoo n C apabilit y Det e rmina tion . The 
next guery with which you will be presented will address the 
ship's Harpoon weapons system capability. The guery is 
shown in Figure 3.26. 



FCF CALIFORNIA 

??? IS THIS UNIT HARPOON CAPABLE ??? 



(YES OR NO) 



Figure 3.26 Query - Harpoon Capability. 



The intent of rhis capability determina- 
tion is to comfirm net only that the ship is capable of 
having the Harpoon system, but also has the weapons onboard. 
As we will see later, this is not a "one time" entry. 
Within the STATUS module is a capability to CHANGE any item 
in the ship's database, and therefore allow for a real time 
maintenance on onboard weapons. Your response would be the 
following, as appropriate. 

KE — YES <cr> or NO <cr> 

VR — "Affirmative" or "Negative" " 

If you make a mistake in entering your YES/NO response, you 
will see the following, after which you simply reenter your 
response . 

PLEASE ENTER YES OR NO 



as 



(6) ?r i gar v /S ec ondar y Air S earch Pa car 
Det e rmin a tion . Similar to the missile syscem 
capability determination, the same menu is utilised for 
deter g ination of the primary/secondary air search radar 
capability. Figure 2.27 shows the composition of the menu. 
As ycc have seen before, the menu will be prefaced by the 
appropriate declaration of which capability (primary or 
secondary) is being solicited. The query for the ship’s 
primary capability is reflected in Figure 3.27. As 

CALI FCENIA has an AN/SPS-48C, the following would be entered 
in response to this query. 

KB — 1 <cr> 

V R -- "One” "Carriage Return" 



FOE CALIFORNIA 

??? WHAT IS HEE PRIMARY AIR 


SEARCH RADAR ??? 


* AIR SEARCH RADAR 


OPTIONS * 


0 — NONE 


6 -- AN/SPS-37 A 


1 — AN/SPS-48C 


7 — AN/SPS-52 


2 — AN/SPS-49 


8 -- AN/SPS-40 


3 — AN/SPS-65 


9 — AN/SPS-39 


4 -- AN/SPS-58 


10 — AN/SPY-1 


5 — AN/SPS-43 A 
SELECT CNE OF THE AEOVE 


i 



Figure 3.27 Query Menu - Air Search Radar Options. 

Once the primary air search radar has been 
determined, the. query for the ship's secondary capability 
will he presented. As you have seen before, if you indi- 
cate that the ship has NO primary capability, then the query 
for the secondary capability will not be presented. If you 
indicate a primary capability, then rhe following preface 
will appear. 
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FOR CALIFORNIA 



WHAT IS HER SECONEARY AIR SEARCH RADAR (IF APPLICABLE) 

The manner in which the capability is entered is the same 
for the secondary capability, and is shown in the following 
example, indicating CALIFORNIA has an AN/SPS-40 for a secon- 
dary air search radar. 

KB — 8 <cr> 

VR -- '’Eight" "Carriage Return" 

Should an error occur in entering either 
the primary or secondary capability, the the warning shewn 

in Figure 3.28 will be presented. On receiving such a 

warning, simply enter CARRIAGE RETURN, and the appropriate 
preface, followed by the menu will appear. Then reenter 
your response. 



YOU WILL HAVE TO REENTER YOUR RESPONSE FRO H THE MENU 
OF TICKS. 

*** PRESS RETURN TO CONTINUE *** 



j 



Figure 3.28 Warning - Response Not From Menu Options. 



(7) Sur face Search R ada r D ete rmination. 
Figure 3.29 shows the query you will be presented with for 
the determination of the ship’s surface search radar. 

CALIFCFNIA has an AN/SPS-10 onboard, therefore, the correct 
response wculd be as fellows. 



9 1 



KB 



3 



<cr > 



FOB CALIFORNIA 



??? WEAT IS HER SURFACE SEARCH RADAR CAPABILITY ??? 



* SURFACE SEARCH RADAR OPTIONS * 



0 — NONE 

2 — AN/BPS-15 

3 — AN/SPS-10 

4 — AN/SPS-55 

5 — AN/SPY-1 



SELECT ONE OF THE ABOVE 



Figure 3.29 Query — Surface Search Radar. 

V R -- "Three" "Carriage Return" 

(8) Pri mary /S e c on dary Fir e Control Radar 
Determination. Particularly important for the 
combatants (non-Service Force ships) is the specification of 
their fire control radar capability. As the system 

addresses both primary and secondary capabilities, the 
procedures for entering this information are similar to 
those utilized with missile systems and air search radars. 
Figure 3.30 shows the menu options for fire control radars. 
The guery for determination of the primary capability is is 
reflected in Figure 3.30. 

Your response would be the number corre- 
sponding to the system you desire. If you indicate that 
the ship dees not have a primary capability, as you have 
seen before, you will not be presented with the guery for 
the secondary capability. A correct response would look 
like the following. 

KB -- 2 <cr > 

V R -- "Two" "Carriage Return" 
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“ 1 


FCR CALIFORNIA 








??? WEAT IS 


HER PRIMARY FIRE CONTROL 


RADAR (IF APPLI- 


CAELE) 


? ?? 
















* 


FIRE CONTROL 


RADAR 


OPTIONS * 




0 


_ _ 


NONE 


10 


_ — 


MK-99 




1 


— - 


MK- S 1 


11 


— - 


MK-74 




2 


— 


AN/SEG-55 A 


12 


— 


MK-68 




3 


— - 


AN/SFG-49 


13 


— — 


MK-92 




4 


— 


AN/SPW-2 


14 


— 


AN/SPG-53 




5 


— 


MK-40 


15 


— 


AN/SPG -60 




6 


— — 


AN/SEG-51 


16 


— - 


MK-13 




7 


- — 


MK-7 


17 


— 


AN/SPQ-9 1 




8 


— — 


MK-76 


18 


— — 


AN/SPG -35 




9 




MK-56 








SELECT 


CNE 


OF 


THE ABOVE 
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Figure 3.30 Query Henu - Fire Control Radar Options. 

If you indicate a primary capability, the 
query fcr the secondary capability will appear with the 
following prefacing the menu cptions. 

FOR CALIFCF NIA 

WHAT IS HER SECONDARY FIRE CONTROL RADAR (IF APPLICABLE) 

The response for the secondary capability 
is of the same format as the primary. Should an error 
cccur in entering ycur response, you will see the warning 
shown in Figure 3.28. As was discussed, when ready, enter 
CARRIAGE RETURN and the appropriate preface and menu will 
appear. Reenter your response. 

(9) UHF/HF Ra d io C apability D ere r mi rat ion . 
One cf the important capabilities of the system is to 
display the communications links within the battle group. 
This is dene in the CCMMS module. The graphics displays of 
the nets is color coded to show nor only the relative 
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distance between participating units, but also their respec- 
tive radio requirements based on mission area. The 
dynamics of the status of communications equipments makes 
this a good indicator of C3 performance. The base for the 
determination of the available radios onboard is the attri- 
tion applied to installed numbers of these radios. This 
number of installed radios is the value desired in this 
guery. The system will differentiate between UHF and HF 
radios. The query/response sequence is straightf oward. 
The query for the number of installed UHF radios is shewn in 
Figure 3 .3 1 . 



FOB CALIFORNIA | 

??? HCW MANY UHF RADIOS DOES SHE HAVE ONBOARD ??? j 

(RANGE 1 TO 9 9) | 

I 

I 

i 1 



Figure 3.31 Query - UHF Radio Capability. 



Identical to the format for the UHF query, 
the guery for the numbers of installed HF radios is shewn in 
Figure 3.32. 



The response to either if these queries is 
of the same format ard an example is as follows. 

KE — 15 <cr > 

VB -- "Cr.e" "Five" "Carriage Return" 

If ycur response is net within the range specified (1 - 99), 
then ycu will see the warning shown in Figure 3.33 on the 
screen. 
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FOE CALIFORNIA 

??? HCW MANY HF RADIOS DOES SHE HAVE ONBOARD ??? 
(BANGE 1 TO 99) 



Figure 3.32 Query - HF Radio Capability. 



you HILL HAVE TO REENTER THIS NUMEER 
*** PRESS RETURN TO CONTINUE *** 



Figure 3.33 ERROR in Entering Integer value. 



After yen enter CARRIAGE RETURN, the applicable query will 
reappear and you can reenter ycur response. 

(10) Sate llit e Commu nic at ions C a pa b ility 

Pet ermina tion . To complete the database for 
the communications capabilities of the ship, you need to 
identify the ship’s satellite comm capability. This is 

very straightf o ward , and the query is shown in Figure 3.3U 
(adjusted). To give the ship a capability indicated in the 
menu, simply enter the number corresponding to the equipment 
desired . 



If you desire to indicate that CALIFORNIA 
has an AN/NSC-3 onboard, ycur response would look like the 
following example. 

KB — 1 <cr> 
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FCE CALIFORNIA 

??? WHAT SATELLITE COMMO N ICATION S CAPABILITY DOSS SHE 
HAVE ??? 

0 — NCNE 

1 — AN/WSC-3 

2 — OS-82 

SEIECI 0 , 1 , CR 2 



Figure 3.34 Query - Satellite Communications Capability. 

VR — "One" "Carriage Return" 

Should you make an error in entering this 
response, then the warning shewn in Figure 3.28 will appear. 
After you enter CARRIAGE RETURN, the SATCOM menu will reap- 
pear, and you can reenter ycur response. 

(11) Gun System Ca pa bility Determina tion. The 
next input to the ship's database is her gun weapons system 
capability. Figure 3.35 (adjusted) shows the query menu 
with the available gun options. 

CALIFORNIA has a 5»/54 MK45 gun. The 
following is an example of how we would enter this informa- 
tion . 



KB — 5 <cr > 

VR -- "Five" "Carriage Return" 

The warning shown in Figure 3.28 will 
appear if ycur response is not within the range of the menu 
options (0 -7). After you enter CARRIAGE RETURN, the 

guery menu will appear and you can reenter your response. 



96 



FOE CALIFORNIA 

??? WHAT IS HER G ON WEAPONS SYSTEM CAPABILITY ??? 

* GUN SYSTEM OPTIONS * 

0 — NOT APPLICABLE 

1 — 1 6 »/5 0 (406 mm) MK7 MOD 0 

2 — 5"/38 (127 mm) MK12 MOD 1 

3 — 2mm/70 MK4 

4 ~ 5"/54 (127 mm) MK42 

5 — 5"/54 (1 27 mm MK45 

6 — 3»/50 (76 mm) MK22 

7 — 7 6 mm (OTO MELARA) 



SELECT ON OF THE AEOVE 






Figure 3.35 Query - Gun System Options. 

(12) PHALANX C ap a bility Determina tion . The 
query shewn in Figure 3.36 requests the number of PHALANX 
systems the ship has onboard. The number of systems can 
range from 2 ero (0) through normally, four (4). 



FOE CALIFORNIA 

??? HOW MANY PHALANX SYSTEMS DOSS SHE HAVE ??? 

Figure 3.36 Query - PHALANX Capability. 



To indicate that CALIFORNIA has three (3) 
EHALANX systems onboard, the following entry would be made. 
Should an error occcr in making this entry, the warning 
shown in Figure 3.33 will appear, and when you continue, the 
guery will again come up, and you cna reenter your response. 

KB — 3 <cr> 
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V R — "Three" "Carriage Return" 

(13) TOMAHAWK Ca£ability. Dete rminat ion. While 
the TOMAHAWK weapons system is relatively new to the fleet, 
this capability will become increasingly available in 
upcoming years. To ensure that this DSS has the ability to 
display the TOMAHAWK capability, this solicitation for 
information will be presented. The query shown in Figure 
3.37 requests the ship's TOMAHAWK capability. In the case 
of our example, CALIFORNIA, she does not have this capa- 
bility. 



FOB CALIFORNIA 

??? IS SHE TOMAHAWK CAPABLE ??? 


(YES OR NO) 











Figure 3„37 Query - TOMAHAWK Capability. 



There is a difference in the intent of 
this query as opposed to that of the HARPOON capability. 
With TOMAHAWK, it is assumed that since few ships have this 
capability, those that do will have the weapons onbcard. 
Therefore, a "YES" response to this query should mean that 
the ship in question has not only the capability, but also 
the weapons. Your response would be the following as 
applicable. 

KE — YES <cr> or NO <cr> 

VF -- "Affirmative" or "Negative" 



Should an error cccur in making this response, you would see 
the fcllcwing on the screen. 

PIEASE ENTEE YES OR NO 
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(14) He 1 ic opt e r C ap ability Determination. The 
helicopter, as a surveillance vehicle or a weapons platform 
is becoming invaluahle to the battle group. The query, 
shown in Figure 3.38, requests information on the helicopter 
capa bili ty cf the ship in guestion. The four helo types, 
present in a battle group are shewn as options. Cr.ce the 
capability has been affirmed, then you will be asked whether 
the the ship actually has its detachment onboard. 



FCR CALIFORNIA 

??? WHAT IS HER HELICOPTER CAPABILITY ??? 
=» HELO OPTIONS * 

1 — NOT CAPABLE 

2 — HC DET (CH-3) 

2 — HS DET (SH-3) 

4 — HC DET (CH-46) 

5 -- HS L DET (SH-2) 



Figure 3.38 Query - Helicopter Capability Determination. 



Eor CALIICENIA, which has a LAtfPS capability, your response 
would be the the following. 

KB — 5 <cr > 

VR — "Five" "Carriage Return" 

Once the capability has been determined to 
exist, you will receive a query regarding the embarcation 
status of the detachment. This query is tailored tc the 
type cf capability you gave the ship. For our example, 
figure 3.39 shows the query. 
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??? DOES CALIFO ENIA HAVE HER LAMPS DET ONBOARD ??? 
(YES CR NO) 



1 




Figure 3.39 Query - LAMPS Embarcation Status. 

As was mentioned, this query is tailored 
to the type of capability you gave the ship. If you had 

indicated that the ship had an HC DET (CH-46) capability, 
then the following would be the query for the embarcation 
status. 

??? DOES < SHI P> HAVE HER "CH46" DET ONBOARD ??? 

(YES CR NO) 

There are similar matches for each capability listed in 
Figure 3.38. 

At this point, an additional capability of 
the system needs to be addressed. We will discuss in the 

STATES module operations, the capability you will have to 
change any item in tte ship's database once the battle group 
has been established. That capability utilizes tha same 
menus and prefaces as does the module in which we are 
working. While that capability will be covered in mere 
depth later (under STATUS Module Operations), reference will 
regularlj be made to these sections for explanation of the 
gueries and appropriate responses with respect to the menus. 
When dealing with the helicopter embarcation status C HA NGE 
ONLY, there is a warning that could appear if you attempt to 
embark a helicopter detachment on a ship to which there has 
keen given NO helo capability. In this case, the warning 
shown in Figure 3.40 will be presented. 
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BASED CN THE INFO E CATION IN THE DATAEASE, THIS UNIT IS 
NO I EEIC CAPAELE. YOU WILL HAVE TO FIRST GIVE HER THE 
CAEAEILITY. 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.40 Warning - Ship Not Helo Capable. 

This situation is not possible when 
working in the BUILD module, which we are discussing, as you 
will ret be queried cn the embarcation status of a ship to 
which you gave no helc capability. 

Should an error occur in making the 
response regarding the capability, the warning shown in 
figure 3.28 will appear. After you continue, you will 
again be presented with the menu, and can reenter your 
response. Should an error occur when you are making ycur 
response regarding the embarcation status, you will see the 
following cn the screen. 

PLEASE ENTER YES OR NO 

At this point, simply reenter yor YES/NO response. 

(15) Sorar /IVD S Ca pabili ty Determin ation. The 
query for the ship's senar capability, shown in Figure 3. 41, 
will net be presented for the Aircraft Carriers, or Service 
Force ships. Also, the assignment of the sonar capability 
is important because in the SENSOR module, some of the 
sonars are "flagged" as being capable for convergence zene 
operations, and that capability will be displayed if you 
indicate that these ccndirions exist. 
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FOR CALIFORNIA 



??? WHAT IS HER SONAR CAPABILITY ??? 
* SONAR OPTIONS * 



0 — NOT CAPABLE 

1 — an/bqc-5 

2 — AN/BQ S- 1 5 

3 — AN/BQC-2 

4 — AN/BQS-6 

5 — AN/BQB-7 



6 — AN/BQS- 1 2 

7 — AN/SOS-23 

8 — AN/SQS-26 

9 — AN/SQQ-23 

10 — A N/SQS- 5 3 

11 — AN/SQS- 56 



Figure 3.41 Query - Sonar Options. 

You would indicate the sonar capability be 
entering the number corresponding to the equipment desired. 
For CALIFORNIA, which has an AN/SQS-53 sonar, your response 
would lock like the following. 

KB — 10 <cr> 

VR — "Ore" "Zero" "Carriage Return" 

Should an error occur in making this response, the informa- 
tion shown in Figure 3.28 would appear. When you continue. 

Figure 3.41 will reappear, and you can reenter your 
response . 

The IVDS capability determination is stra- 
ightfcward, and requires only a YES/NO answer. The query 
for this information is shown in Figure 3.42. 

CAIIFCRNIA does not have this capability, 
therefore we would enter NO. The response, in general, 
would be the following as applicable. 

KB — YES <cr> or NO <cr> 

VR -- "Affirmative" or "Negative" 
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J 

I 

FOB CALIFORNIA | 

* I 

??? DC E £ SHE HAVE AN IVDS CAPABILITY ??? (YES OR NC) | 

I 



Figure 3.42 Query - IVDS Capability. 

Should ycu make an error in responding, you will be directed 
to enter ycur YES/NC response again, as we have seen 
earlier. 

(16) TASS Ca q ab il ity Determinat ion. The 

deter irinaticn of the TASS capability applies to only to 
submarines, destroyers, cruisers and frigates. This guery 
will net be presented for ships not in those ship types. 
Figure 3.43 shows the composition of the query. 



FOB CALIFORNIA 

??? WHAT IS HER TASS CAPABILITY ? ?? 

0 — NOT APPLICAEIE 

1 -- AN/SQR- 1 9 (IMPROVED TACTASS) 

2 — AN/SQR-18 (TACTASS) 



Figure 3.43 Query - TASS Capability. 

The response to this guery is the number corresponding to 
the desired capability. CALIFORNIA does not have this 

capability, therefore the response would be as follows. 

KB — 0 <cr> 

VR — "Zero" " Carriage Return” 
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Should an error occur in making this response, then the 
warning shown in Figure 3.2£ will be presented. After you 

continue, the TASS Capability menu will again be presented, 
and you can reenter ycur response. 

(17) ASK Rcck et/Torpedo Capab ility 

Determina tion . The determination of the ASW 
weapons capability fcr the units of the battle group is 
discussed tcgether. These capabilities are not applicable 
to aircraft carriers and service force ships, and therefore 
the gueries will not be presented for those units. The 
composition for the query fcr determination of the ASW 
rocket capability is shown in Figure 3. 44. 



FCR CALIFORNIA 

??? WHAT IS HER ASW RCCKET CAPABILITY ??? 

N — NOT AEELICABLE 
A — ASROC 
S — SUB ROC 



Figure 3.44 Query - ASW Rocket CApability. 



This is the first query menu that requires a response that 
is a character and net a number. Also, there is no system 
check of the input ycu make, sc, you could give a SUBRCC (a 
submarine weapon) to a surface ship. This fact is 

mentioned net to encourage you to do this, but rather to 
alert you to the possibility of error without system correc- 
tion. The response desired is mads by entering the char- 
acter corresponding to the desired capability. CALIFORNIA 
has an ASROC capability, therefore the response would be as 
follows . 
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KB 

VR 



A 



<cr> 



" ASROC" ’’Carriage Return" 

The system looks for a response that has no numbers and 
either the "N," "A,” or "S” characters. Should ycur 

respcrse net be any cf those inputs, then you will see the 
warning shown in Figure 3.28. After you continue, the menu 
will te again presented, and you can reenter your response. 

The determination of the ship's torpedo 
capability is similar to other queries you have seer.. The 
composition for the query is shown in Figure 3.45. 



I 

FCB CALIFORNIA j 

??? WHAT IS HER TORPEDO CAPABILITY ??? | 

C — NOT APPLICABLE I 

1 -- MK 46 | 

2 — MK 48 I 



i i 



Figure 3.45 Query - Torpedo Capability. 



The input should be the number corresponding to the desired 
capability. CALIFORNIA has a MK46 torpedo capability, 

therefore, the correct response would be as follows. 

KB — 1 <cr> 

VR — "One” ” Carriage Return" 

Should an error occur in making this response, the the 
warning shown in Figure 3.28 will be presented. After you 

continue, the menu will be again presented and you can 
reenter ycur response. 
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(18) Maximum 3 peed P et er m inat ion ♦ The desired 

value of this input is the designed maximum speed for the 
ship in question. In the CHANGE function of the STATUS 
module, this value can be kept current, as a real time indi- 
cator of the ship's mobility capability. In the STATUS 
module, you can adjust this value as the situation dictates. 
The composition for the query is shown in figure 3.46 . 



FCE CALIFORNIA | 

??? WHAT IS EER MAXIMUM SPEED IN KNOTS ??? | 

(RANGE 1-40 KNOTS) | 



Figure 3.46 C^ery - Maxiaua Speed Capability. 



The response to this query should be the ship's maximum 
speed, within the ranee given (1-40 knots). The CALIFCENIA 
has ar unclassified maximum speed of 33 knots, and this 
information would be input as follows. 

KB — 33 <cr> 

VE — "Three" "Three" "Carriage Return" 

The system will check the input to ensure that it is within 
the allowable range. Should the input not be within this 
range, the warning shewn in Figure 3.33 will be presented. 
After you continue, the query shown in Figure 3.46 will 
again be presented, and you can reenter your response. 

(19) SL£;32 Capability Det-ermina tier. . The 

composition of the guery for a ship's SLQ-32 capability is 
shown in Figure 3.4*/. The required input is a YES or NO 
response . 
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r 



FOE CALIFORNIA 

??? DOES SHE HAVE AN SLQ-32 CAPABILITY ??? 
(YFS CR NO) 



Figure 3.47 Query - SLQ-32 Capability. 



CALIFCFNIA does not have this capability, therefore the 
correct response would be NC. As applicable to the partic- 
ular ship, the response would be as follows. 

KE — YES <cr > or NO <cr > 

VF — "Affirmative" or "Negative" 

Should an error cccur in making this response, the following 
statement will appear. 

PLEASE ENTER YES OR NO 

If this occurs, simply reenter your YES/NO response. 

(20) P r itr ary/ S ecc n d ary Mission Determination. 
The same menu is utilized for the determination of both the 
primary and secondary missions of a ship. Figure 3.49 
shows the composition of this menu. The specific mission 
desired (primary or secondary) will be specified in a 
preface to the menu. The preface for the determination of 
the ship's primary mission is shown in Figure 3.48. Fcr 
the purposes of this system, every ship MUST have a primary 
mission. Therefore, you will not be allowed to enter "NOT 
APPLICABLE" for a ship's primary mission. 
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FCE CALIFORNIA 



??? WHAT IS HER SECONDARY MISSION ??? 



Figure 3.50 Query - Secondary Mission Area. 

This query would be followed by the mission options shewn in 
Figure 3.49. The CALIFORNIA has a secondary mission of 

ANTI- SUBMARINE WARFAFE, therefore the correct input far 
secondary mission area would be as follows. 

KB — ASW <cr > 

VR -- '’Anti-Submarine Warfare" 

The system will attempt to match your response to these 
options shewn in the menu, and if there is no match, an 
error will occur. Should this happen, the warning shown in 
Figure 3.28 will be presented. After you continue, the 

applicable query will again be presented, and you can 
reenter your response. 

d. Completion of Database Assembly 

The complete sequence of capability menus, as 
applicable to the ship types in question, will be presented 
for all ships listed in the view shown in Figure 3.18. 
Cnee these capabilities have been compiled for all of the 
ships in the battle croup, whether it be done automatically 
or manually, you are ready to proceed to the next phase of 
Initially Forming the battle group database, determination 
of the positions of the ships. This is the topic of the 
next section. 
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e. Establishing Unit Eositions 

Now that the names and capabilities of the ships 
which will comprise the battle group have been determined, 
the r*xt information required by the system is the position 
cf each ship. There are generally three segments tc this 
section cf the BUILD module. First, the unit which will be 
in "ZZ" will be determined. Bemember that for the purposes 
of this system, a battle grcup ship must be at "ZZ." Next, 
the type cf coordinate system to be used (polar cr carte- 
sian) , will be determined. Finally, the positions fcr the 
individual ships will be input. Let's first look at deter- 
mining the unit to be at "ZZ." 

(1 ) Pet er minat icn cf " ZZ" unit. The specifi- 
cation cf the unit tc be at "ZZ" is critical to the opera- 
tion cf the remainder of the modules in the system. It is 
with respect to this unit that all of the computer graphics 
coordinates for each ship will be calculated. The calcula- 
tion cf these graphics coordinates is done by the system and 
will be transparent tc you. The only information required 
will be the normally assigned ship positions, in terms of 
the coordinate system you select, and the system will adapt 
those positions for graphics use. Irrespective of the coor- 
dinate sjstem you specify, the position of the unit at "ZZ" 
will have to be input in cartesian coordinates, as these 
adapt more readily tc graphics coordinates. This query 
will be discussed shortly. 

The query shown in Figure 3.51 addresses 
the determination of the unit to be at "ZZ." As you will 
now see throughout the remainder of this Decision Support 
System, whenever a requirement is levied to name a partic- 
ular unit cf the battle group, there will be a current 
listing of the battle group provided along with the query. 
Ihis listing shews all of the batrle group units as rhe 
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system has filed their names. Figure 3.51 shows the compo- 
sition of our example tattle group to assist you in identif- 
ying the unit you desire. 



??? WHICH 


UNIT WILL FUNCTION 


AS ZZ ??? 


— 1 
1 


CARL VINSON 


PAUL F FOSTER 


CALIFORNIA 


1 

1 

1 

1 



Figure 3.51 



Query - Name of ZZ Unit. 



The listing of ships will always be in three columns. 

Since there are only three ships in the example battle 

group, there is only one line. As you found when you 

entered the names of the ships earlier, the spelling of the 

name is critical for the system to recognize the entry. 
Every time there is a request for identification of a unit, 
the system will attempt to match the input name tc those in 
the tattle group. Should a match not occur, then you will 
be asked tc reenter the response. In order to use the name 
of a unit, for any function, it must be first INSERTed into 
the battle group database, as we have already done for cur 
three example ships. Even though the listing shews "PAUL F 

FOSTER," the system has been programmed to recognize 
"FOSTER" as an acceptable version for the same ship. This 
is also true for "CARL VINSON", as the system will recognize 
"VINSON" as the same ship. In general, this applies tc all 
ships with two or more words in their names. The last name 
cf the ship has been programmed to be an alternatively 
acceptable name representation. These differences, in 

reality, apply both to keyboard as well as voice entry. 



For vcice entry, refer tc Appendix A for a detailed listing 



of all legit ima te ship names an 
assign the CARL VINSCN to "ZZ." 
he as fellows. 

K3 — CARL VINSON <cr> 
VS -- "CARL VINSON" 

If there was a mechanical error 
the following alert would be dis 

ELEASE REENTER THE NAME 



d their variations. Let's 
The correct response would 

or VINSON <cr> 

or "VINSON" 

in making this entry, then 
played. 

OF THE ZZ UNIT AGAIN 



If there had not been a match of the input name with these 
of the listing (for example if you had input NIMIT2) , then 



YODR ENTSY FOR ZZ NIMITZ DOES NOT MATCH ANY OF THE 
SHIE NAMES IN YOU? EATTLE GFCUP. PLEASE CHECK TEE 
SPELLING AND COMPLETENESS OF YOUR ENTRY. 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.52 ERRCB - ZZ Naae Not Matched To Listing. 



you would be shown the warning shown in Figure 3.52. 



When you continue, you will again be presented with the 
query shewn in Figure 3.51, and you can reenter your 
response . 



miration of the 



The next 
coor dinate 



query you will see is 
system to be utilized. 



for deter- 



(2) Determination of Coordinate System. There 
are twe choices for coordinate systems on which to bass your 
ship's positions, polar or cartesian. The query which 
addresses the coordinate system is shown in Figure 3.53 
(adjusted) . 
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YOU WILL NOW EE ASKED FOB TEE POSITION OF EACH UNIT IN 
THE EATTLE GROUP. 

??? WCULD YOU LIKE TO USE POLAR OR CARTESIAN POSI- 
TIONS ??? 

(ENTEF "EOLAR” OR •'CARTESIAN”) 



Figure 3.53 Query - Coordinate System. 



The format of the response to this query, as well as the 
query sequences which respectively follow each response 
option are shown in sutsequent sections. Should you make 
an error ir. entering the response to the query shown in 
Figure 3.53, the following will be presented. 

PLEASE ENTER "PCLAF” OR "CARTESIAN” 

Fememter not to induce the quot as. Once the type of coor- 
dinate system has been specified, you are asked fcr the 
cartesian position of the unit at ”ZZ” (CARL VINSON, in our 
example) . This query is shown in Figure 3.54. 



FCB CURL VINSON 

??? WEAT IS HER POSITION IN CARTESIAN COORDINATES ??? 

(ENTER AS QUADRANT (R,W,E,G), SPACE, X-POSITION, SPACE, 
i - EOS IT I CN) 

(E.G. W 030 0S0) 

i i 



Figure 3.54 Query - Cartesian Position of ZZ Unit 



The format cf the response to this query, 
and the corrections tc any errors which you might encounter 
in making this response, are identical to these which you 
see for the input cf a cartesian position for any ether 
ship. Please refer tc the section on Query Sequences — 
Cartesian Coordinate System, below. This will be the only 

time you are asked for the position of the unit at "Z2," 
unless you delete this unit from the battle group, in which 
case you will have tc reinitiate the position determination 
sequences. He will new lock at the sequences which you 
will encounter based on the type of coordinate system you 
specify. 

(3) Query S e q uenc es -- Pol££ C oo rd inate 
System . In response to the query shown in 
Figure 3.53, if you desire to input batrle group positions 
in polar coordinates, the correct format for the response 
would be as follows. 

KB — POLAR <cr > 

V R -- "Polar Coordinate System" 

Once you have selected this coordinate system, you will be 
sequence through each ship (less the unit at "ZZ") , being 
gueried for its bearing and range from "ZZ." You will first 
be asked for the ship's bearing from "ZZ," in degrees true. 
Next, ycu will be asked for the ship's range from "ZZ," in 
YAR DS . After you have entered a ship's position, that 
position will be presented tc you for confirmation. The 
initial cuery is shown in Figure 3.55. 



If PAG! 
then the 

KB 

VR 



F FOSTER were bearing 090 degrees true 
correct response tc this query would be 

090 



from "ZZ," 
as follows. 

<cr> 



"Zero" "Nine" "Zero" "Carrrage Return" 
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FOB PAUL F FOSTER 



??? WHAT IS HER BEARING AND RANGE FROM ZZ ??? | 
??? E EARING ??? | 
{ ENIEB AS THREE DIGITS 000-359) | 



Figure 3. 55 Cuery - Ship*s Bearing From ZZ. 

The system will check the input against the authorized range 
(000-359) , and should the input not be within this ranee, 
then the following warning will be presented. 

PLEASE ENTER AS THREE DIGITS (000-359), WITHOUT COMNAS OR 
EECIHAL POINTS 

*** PRESS RETURN TO CONTINUE *** 

When ycu continue, you will again be presented with the 
query shown in Figure 3. 55, and you can reenter ycur 

response . 

You will next be asked tc indicate the 
ship’s range from "ZZ. " This range input should be in 
yards, and entered without any commas or decimal points. 
The guery is shown in Figure 3.56. 

As an example, PAUL E FOSTER is 50,000 yards (25 nm) from 
"ZZ. " The correct response to this query wculd be as 
follows. 

KB — 50000 <cr > 

V R — ""Five" "Zero" "Thousand" 

Should an error occur in making this entry, the warning 
shown in Figure 3.57 would be presented. 
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FOE FAUL F FOSTER 

??? WHAT IS TEE SHIFTS RANGE FROM ZZ ??? (IN YARDS) 

(ENTER AS SIX DIGITS WITHOUT COMMAS OR DECIMAL POINTS 
E.G. 10,000=10000 RANGE LIMITS 0 TO 600,000 YARDS) 



Figure 3.56 Query - Range From ZZ. 



PLEASE ENTER THE RANGE AS SIX DIGITS WITHOUT COMMAS OR 
DECIMAL POINTS. 

(E.G. 5,000=5000, £00,000=500000, ETC.) 

*** PRESS RETURN TO CONTINUE *** 



Figure 3.57 ERROR - Range Input. 

When you continue, the query for range 
(Figure 3.56) will again be presented, and you can reenter 
your response. The system will also check your input 
against the range limits (0 to 600,000 yards) . Should ycur 
input net be within these limits (for example 700000 was 
input), then the warning shown in Figure 3.58 will be 
presented. As with ether error corrections, when you 

continue, the original query will be presented, and you can 
reenter ycur response. 



Once the bearing and range have been 
correctly input, the values are presented to you fer confir- 
mation. The format for this confirmation is shown in 

Figure 3.59, and requires a YES/NO response. 
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YOU HAVE ENTERED 7C0000 AS THE RANGE AS THIS UNIT'S 
RANGE, AND THIS IS NOT WITHIN THE RANGE LIMITS. 



11 

Figure 


3.58 


ERRCE - Range Outside Prescribed 


1 

Limits. 


■ 

PAUL E 


FOSTER IS EEARING 90 DEGREES TRUE AND 


RANGE 


5 0 00 C 


YARDS 


FROM 22. 






♦ • • 


IS THIS CORRECT ??? (YES/NO) 


i 



Figure 3.59 Query - Bearing/Baage Confirmation. 

The following is the correct response to this query as 
applicable . 

KE — YES <cr> or NO <cr> 

VR — "Affirmative" or "Negative" 

Should a mistake occur in making this response you will see 
the following: 

PLEASE ENTER "YES" OR "NO" 

Simply reenter ycur YES/NO response. If you enter "YES," 

then you will either sequence to the next ship requiring 
position input, or if no more ships require positions, you 
will move to the nest section of zhe EUILD module, estab- 
lishing the Composite Warfare Commander (CWC) Organization. 
If you had entered NC to the position confirmation query, 
then the query shewn in Figure 3.55 would again be 
presented, and you would repeat the position entry sequence 
for that ship. 
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(4 ) Query Seq uence -- Cartes ian Cccr din ate 
Sys t em. In response to the query shown in 
figure 3.53, if you desire tc input the positions of the 
tattle group units in cartesian coordinates, then you would 
enter the following. 

KB — CARTESIAN <cr> 

VR — "Cartesian Coordinate System" 

You would then he queried for the cartesian positions of 
each ship in the battle group (less the unit at "ZZ"). The 
format fcr the specification of the position is Quadrant, 
X-Cocrdinat e, Y-Cocrdinat e. Each of these entries is 
separated by a space, as shown in the query example. The 
composition of the query is shewn in Figure 3.60. 



FOR PAUL F FOSTER | 

??? WHAT IS HER POSITION IN CARTESIAN COORDINATES ??? | 

(ENTER AS QUADRANT (R,W,E,G), SPACE, X-FOSITION, | 

SPACE, Y-POSITION) | 

(E.G. W C30 0 90) j 

I 



Figure 3,60 Query - Cartesian Position. 



To demonstrate the correct format for the cartesian position 
input, let's give PAUL F FOSTER the position WHITE 15C 1G0. 
Particularly when entering your response from the keyboard, 
it is important to conform exactly to the format for the 
response. There can be NO extra spaces. When making the 
input by voice, while the input command has some length, 
this is not a problem when you follow rhe example. 

K3 — W 150 1 00 <cr> 
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